Update named.conf.local.jinja
Some reorganization of the format.
In the for-loop that handles configured_views:
- Add if-block on lines 124-128 to allow specifying a file for your view, rather than defaulting to the name of the specified zone. This allows multiple views to serve the same zone, but use a different file.
Update pillar.example
Add documentation and an example on specifying the file to be used for a view, as well as documented that you should not define the top-level 'configured_zones' key when using views.
Small comment update.
Add comment about using ACLs and views.
Create pillar-with-views.example
An example of the bind pillar that defines multiple views for internal and external record sets.
This doesn't include the other portion of the pillar the defines the bind config - this is zones, views and ACLs only. The config portion is not affected by this.
Add more comment clarification.
Add comment explaining file name requirements.
The filename must match the corresponding zone name (without the .txt extension) because the config.sls jinja logic uses the filename to match to the zone when setting zone_records. It also is hardcoded to replace ".txt" with "" in order to make this match work, and so .txt extension is required for the logic to work.
Update config.sls
Add logic to detect a file specified in a view, and match it to a zone under available_zones to enable creating that zone file.
Revert back
Made a bad commit.
Update with the required logic.
Added an if-block to test for the file argument in the zone_data, and if found, use that view and update the zone variable to match the zone defined under available_zones.
Fix variable set.
Set zone based on file with the .txt extension removed.
Update README.rst
Add paragraph about using views.
Update pillar-with-views.example
Add some more comments for explanation.
Added an if-block to test for the file argument in the zone_data, and if found, use that view and update the zone variable to match the zone defined under available_zones.
The filename must match the corresponding zone name (without the .txt extension) because the config.sls jinja logic uses the filename to match to the zone when setting zone_records. It also is hardcoded to replace ".txt" with "" in order to make this match work, and so .txt extension is required for the logic to work.
An example of the bind pillar that defines multiple views for internal and external record sets.
This doesn't include the other portion of the pillar the defines the bind config - this is zones, views and ACLs only. The config portion is not affected by this.
Add documentation and an example on specifying the file to be used for a view, as well as documented that you should not define the top-level 'configured_zones' key when using views.
Some reorganization of the format.
In the for-loop that handles configured_views:
- Add if-block on lines 124-128 to allow specifying a file for your view, rather than defaulting to the name of the specified zone. This allows multiple views to serve the same zone, but use a different file.
pillar.example seems to have been moved to the root of the repository. Tried to make it a link but that only seems to work in Markdown, not in RST 🤷♂️
To process hash entries in deterministic order.
Without this patch, config entries were different for every run
and required a service restart when nothing actually changed.
Doing it similar to
0fe2f7e66b
As all but Debian based distros seem to put the zonefiles in
`named_directory` itself it's been removed from `map.jinja` for all but
debian.
Within `bind.config` we set `zones_directory` to `named_directory` if
not defined in `map.jinja`/pillar.
All zonefile actions then write using the `zones_directory` variable.
This allows the `named_directory` to be the base bind directory as it should so it can be used as a base variable for other directories. Then use the `zones_directory` for placing the zone files in.
