-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature new templates set #54
base: main
Are you sure you want to change the base?
Conversation
Note: I'm doing this PR from a personal fork, because I had a very strange problem with our University's fork. |
c1426d3
to
1e1d0c5
Compare
Can you rebase the branch on the current main branch? The molecule/docker directory, is not necessary anymore. |
bind9_authoritative: no | ||
# variable by default templates and as conditionnal of several tasks | ||
# If using `strict_authoritative/` templates, this variable _must_ be true | ||
bind9_authoritative: "{{ true if bind9_templates == 'strict_authoritative/' else false }}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think yes or no would be better the better choice here since all other variables are also yes or no.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this conditional default definition I want to achieve two goals:
- preserve the default value
no
(orfalse
, better to avoid warning in lint) for the default templates, avoiding breaking behavior in other deployments of the role, - set the value to
yes
when selectingstrict_authoritative
templates, as it is always needed for the role's tasks logic to configure zones.
defaults/main.yml
Outdated
@@ -32,15 +35,23 @@ bind9_hidden_master: no | |||
# Necessary to keep traffic between nameservers in private network. | |||
bind9_notify_explicit: no | |||
|
|||
# bind9_notify: '{{ "explicit" if bind9_notify_explicit else undef }}' | |||
# undef doesn't work here. f**k legacy bind9_notify_explicit variable? | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment not necessary to merge, since it's not used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. And it's not very nice for the author of this variable... Sorry.I was supposed to be development temporary notes.
# Default zone type | ||
bind9_zone_type: master | ||
|
||
## //!\\ Several of the following variables have different meanings or (no meaning at all) depending on the templates' set you use | ||
## See here after bind9_template variable. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment not necessary to merge, since it's not used
defaults/main.yml
Outdated
# bind9_masters: | ||
# - name: ns-primary | ||
# addresses: | ||
# - 1.2.3.4 | ||
# For BIND 9.17.3 (not yet in debian): https://downloads.isc.org/isc/bind9/9.17.3/doc/arm/html/notes.html#feature-changes | ||
# Let's progressively rename this variable with bind's preferred terminology: | ||
# bind9_primaries: "{{ bind9_masters }}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment not necessary to merge, since it's not used
defaults/main.yml
Outdated
# `allow-transfer` may include `acl` lists but not `masters` ones. In YAML role's variables structures are identical, but | ||
# if they appear in BIND configuration list inclusions it will fail. | ||
# Practically: if you use `masters` lists (defined with `bind9_masters`or `bind9_masters_extra` variables of this role), | ||
# yo must re-define separately `bind9_also_allow_transfer`, probably defining an ACL with same values than master lists. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment not necessary to merge, since it's not used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now, it is indeed redundant with the README documentation, but this part is quite important to undertand why in the role you can mix references to masters lists and acls, while in BIND9 configuration you can't.
I think it deserves to be recalled in this file, but as you wish.
defaults/main.yml
Outdated
# It's files live in {{ role_path }}/templates/strict_authoritative/ directory | ||
# Note that several default variables `bind9_*` have different meanings than with default templates' set. | ||
# bind9_templates nust be set as a relative or absolute directory, including it's trailing "/": | ||
# bind9_templates: strict_authoritative/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think comment should go above bind9_templates value :)
@@ -5,7 +5,7 @@ galaxy_info: | |||
description: Role to install and maintain the Bind9 nameserver on Debian | |||
company: systemli.org | |||
license: GPLv3 | |||
min_ansible_version: "2.4" | |||
min_ansible_version: '2.10' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this version bump necessary ?
meta/main.yml
Outdated
@@ -16,3 +16,5 @@ galaxy_info: | |||
versions: | |||
- bullseye | |||
- buster | |||
notifications: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The notifications are also not necessary anymore
templates/bind/named.conf.local.j2
Outdated
{% for master in bind9_masters %} | ||
masters {{ master.name }} { | ||
masters "{{ master.name }}" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this change necessary? In strict_authoritative templates it's without ""
Thanks for the PR. In general I was wondering how you would like to use the variables , if there are commented. Wouldn't it make sense to leave them in and rename the variables depending on which templates they are used. So all variables which go into the strict_authoritative templates are preseed with bind9_strict_authoritative_ ... |
It's an interesting proposal, and could be for the variables which are specific to this set of templates. But for some variables it won't work, for example for However, for me, a better goal would be to consider this proposal:
If you consider this can be a common path, I would be glad to propose the merge of the two role. If not, I'm always concerned about micro-communities an their yet-another-abandonware, but maybe I work it out even. |
Sorry I started a new review, inestead of answering yours. |
Hello, hereafter we propose you a PR we already talked you about. It consists essentially in a new set of templates for stronger, strict authoritative nameservers.
We explored the possibility to include the new features in the default template set (and we indeed included some enhancements for these templates, but it is secondary), finally it was more productive to develop a new set where we try to follow another design than the default ones.
The new set of templates is quite extensively documented, and in the readme we will also see that it led us to develop a sister role that may interestingly enhance it.
In fact, considering coding only, it also deserves to merge the two roles in a single one, with a refactor of the code and the design of a new version of the API of the role. But I think it isn't good to do that without discussing it with you and preparing it for the community of users of the role.
The quite barroque solution proposed: ansible code that writes locally ansible configuration should allow to explore the possibilities without loosing the present role and its simple evolutions.
Closes #38, as this PR is a proposal of its implementation.