dnsimple / chef-pdns Goto Github PK
View Code? Open in Web Editor NEWDevelopment repository for DNSimple Cookbook PowerDNS.
Home Page: https://supermarket.chef.io/cookbooks/pdns
License: Apache License 2.0
Development repository for DNSimple Cookbook PowerDNS.
Home Page: https://supermarket.chef.io/cookbooks/pdns
License: Apache License 2.0
We need systemd support specially for modern distros that are failing converge in integration tests.
In an effort to submit a PR to fix some things, I've noticed that the testing has gone out of whack.
One change that's simple I noticed was a record reply change:
diff --git i/test/integration/recursor-multi/default_spec.rb w/test/integration/recursor-multi/default_spec.rb
index ebc972e..0dc7ba6 100644
--- i/test/integration/recursor-multi/default_spec.rb
+++ w/test/integration/recursor-multi/default_spec.rb
@@ -39,9 +39,9 @@ describe command('dig -p 54 chaos txt version.bind @127.0.0.1 +short') do
end
describe command('dig -p 53 @127.0.0.1 dnsimple.com') do
- its('stdout') { should match(Regexp.new(/208.93.64.253/)) }
+ its('stdout') { should match(Regexp.new(/104.245.210.170/)) }
end
describe command('dig -p 54 @127.0.0.1 dnsimple.com') do
- its('stdout') { should match(Regexp.new(/208.93.64.253/)) }
+ its('stdout') { should match(Regexp.new(/104.245.210.170/)) }
end
Maybe removing that test is best and instead use the version.bind.
or other DNS info calls.
Attaching logs for other verify and converge fails for debugging
There is no :disable action for any resource.
Both recursor and authoritative, sysvinit and systemd resources should have one.
The suite is currently failing with:
[2017-05-29T11:14:04+00:00] ERROR: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/chef/embedded/lib/ruby/site_ruby/2.4.0/x86_64-linux/pg_ext.so) - /opt/chef/embedded/lib/ruby/site_ruby/2.4.0/x86_64-linux/pg_ext.so
Hello,
We've tried to activate or update your repository on Depfu and couldn't find any supported dependency files. If we were to guess, we would say that this is not actually a project Depfu supports and has probably been activated by error.
Please note that Depfu currently only searches for your dependency files in the root folder. We do support monorepos and non-root files, but don't auto-detect them. If that's the case with this repo, please send us a quick email with the folder you want Depfu to work on and we'll set it up right away!
Please note that using the "All Repositories" setting doesn't make a lot of sense with Depfu.
Please let us know by sending an email to [email protected].
This is an automated issue by Depfu. You're getting it because someone configured Depfu to automatically update dependencies on this project.
Seems that the configuration files may not be using the pdns user; and instead use root
In the case of recursor, using rec_control
to reload the config results in:
Encountered error reloading zones, keeping original data: Unable to re-parse configuration file '/etc/pdns-recursor/recursor-__name__.conf'
This was resolved by the performing one of the following:
0644
https://github.com/dnsimple/chef-pdns/blob/master/resources/recursor_config.rb#L85
https://github.com/dnsimple/chef-pdns/blob/master/resources/authoritative_config.rb#L86
This is the first time I use chef. So bear with me here.
If I remove the part that stops the pdns process and do a 'kitchen converge' I end up with an error. The script tries running "pdns_authoritative_service" to enable and start the process. But It can't as a pdns process is already running. I have to stop the pdns process before "pdns_authoritative_service" runs without a hitch. Not sure if I'm doing anything wrong, but I found it strange that is is not working out of the box so to speak
Chef 10 has been deprecated for some time and we should set compatibility to Chef 11 or 12 and above for the next major release.
We're currently moving everything to Chef 12 for production and I'm eager to hear from any users of this cookbook if a move to Chef 12+ compatibility would greatly affect you.
To be more inline with our internal and community guidelines, we need to do the following:
chef-pdns
Our internal wrapper cookbook has been failing converge after 3.3.1 release.
The reason is that the service
block that stops the initial pdns-recursor service installed by the package itself behaves different in Vagrant and Docker as providers.
The following block part on pdns_recursor_service_sysvinit:
service 'pdns-recursor' do
supports restart: true, status: true
action :disable
end
update-rc.d
.update-rc.d
I have been able to reproduce this by simply running a recipe:
pdns_recursor_install 'instance' do
action :install
end
pdns_recursor_config 'instance' do
action :create
end
pdns_recursor_service 'instance' do
action [:enable, :start]
end
And running it with Vagrant and Docker providers (using: export KITCHEN_LOCAL_YAML=.kitchen.dokken.yml
for Docker).
Chef fails in Vagrant, but converges fine with Docker.
Hi,
I was trying out the test recipe given and I get the below error.
The string pdns_authoritative_service[]' is not valid for resource collection lookup. Correct syntax is
resource_type[resource_name]'
/var/chef/runs/cc707120-4eb1-4025-b2f9-f71d9a2746f9/local-mode-cache/cache/cookbooks/powerdns/recipes/authoritative_setup2.rb:49:in block in from_file' /var/chef/runs/cc707120-4eb1-4025-b2f9-f71d9a2746f9/local-mode-cache/cache/cookbooks/powerdns/recipes/authoritative_setup2.rb:39:in
from_file'
/var/chef/runs/cc707120-4eb1-4025-b2f9-f71d9a2746f9/local-mode-cache/cache/cookbooks/powerdns/recipes/authoritative_setup2.rb:
42: variables(
43: gpgsql_host: '127.0.0.1',
44: gpgsql_user: 'pdns',
45: gpgsql_port: 5432,
46: gpgsql_dbname: 'pdns',
47: gpgsql_password: 'mypassword'
48: )
49>> notifies :restart, 'pdns_authoritative_service[]'
50: end
51:
52: file '/etc/powerdns/pdns.d/pdns.local.gmysql.conf' do
53: action :delete
54: only_if { File.exist? '/etc/powerdns/pdns.d/pdns.local.gmysql.conf' }
55: end
56:
57: pdns_authoritative_service '' do
58: action [:enable, :start]`
Am I missing anything?
I'm slightly confused as this recipe tries to install pdns-server but no such package exists. It's called 'pdns' instead:
And use newer Chef 12+ native providers instead.
converge will fail on centos 6.5 because of debian hardcode it pdns.conf path.
I'm sure, other RHEL based distros affected too
Hello,
Could you enlighten me: I was wondering why the debug
property in the pdns_authoritative_install_rhel
and pdns_recursor_install_rhel
does not install the debuginfo package, since the debug repository is created why not also installing the debuginfo package?
Regards,
JM
For homogeneity with the rest of the backends.
This is an upstream bug: PowerDNS/pdns#5439
TL;DR: PowerDNS refuses to start if the PID directory does not exist before, this may present problems in a few situations, being the most important after a server reboot.
I'm planing to create a new release that fixes it, at least on ubuntu 14.04 .I don't have means to reproduce it in RHEL since it requires a physical server that should be rebooted It will be fixed on RHEL too.
The mysql_client resource should be used instead of include_recipe 'mysql::client'
ExampleException in home#example
Something really bad happened
app/controllers/home_controller.rb:123 - example
app/controllers/other_controller.rb:12 - broken
lib/important/magic.rb:4 - load_something
Created by Simone Carletti via Bugsnag
This library is missing upon building a source package, it should be included by default.
Which are missing.
PowerDNS refuses to start if there is a backend specific option and that backend is not installed.
Currently default attributes such as node['authoritative']['config']['pipe_command']
make the server refuse to start when installing other backends but not pipe
backend.
A more intelligent way of dealing with this behavior is desired.
CentOS 8 does not allow us to properly set a higher priority to the powerdns-authoritative
package through yum (as we do for other distributions). Hence we run into situations (as mentioned in #124) where the epel
repo gets priority over powerdns-authoritative
one. i.e.:
centos-7
pdns.x86_64 4.5.3-1pdns.el7 @powerdns-authoritative
pdns-debuginfo.x86_64 4.5.3-1pdns.el7 @powerdns-authoritative-debuginfo
centos-8
pdns.x86_64 4.6.0-1.el8 @epel
pdns-debuginfo.x86_64 4.5.3-1pdns.el8 @powerdns-authoritative-debuginfo
Those tests are missing.
The source recipe fails with
---- Begin output of ./bootstrap && ./bootstrap ----
STDOUT:
STDERR: sh: 1: ./bootstrap: not found
---- End output of ./bootstrap && ./bootstrap ----
If pdns-recursor has previously been installed from the default CentOS repository, the pdns cookbook does not attempt to upgrade it.
Hello everyone,
On your current implementation for the resource pdns_recursor_install
there is no way to change the PowerDNS repositories. In our use case, we tend to mirror all our dependencies, so it would sweet to have this feature.
The same would go the pdns_authoritative_install
.
Regards,
JM
For starters yum_package doesn't work, switching to package is probably the easiest solution
Hello,
I was wondering why you didn't use the pdns-recursor "Virtual Hosting" feature for this provider? Since it seems to be the same to use pdns-recursor for systemd, shouldn't this be a requirement for not having the same way of configuring services (sysv and systemd)?
Regards,
JM
Hello,
Our chef infra system has pre-checks in place to enforce certain ignore files are present to stop uploading of files that do not belong to the core cookbook's working (and to limit the bloat of the chef infra server database a bit).
One of these is the 'test' directory.
In the v8.0.2 on supermarket.chef.io release this directory is present and we cannot upload this version because of this.
Could you maybe implement a chefignore like the one sous-chef is using?
Example: https://github.com/sous-chefs/ntp/blob/master/chefignore
I would really appreciate a quick v8.0.3 release with the chefignore in there to remove the test directory.
Thanks!
Opening this for discussion as I'm not sure what needs to be done yet. This is only related to the pdns-recursor.
I think the deployment model for this cookbook currently conflicts with how CentOS 7 installs and configures pdns-recursor.
I used only the install LWRP:
pdns_recursor_install 'pdns-recursor' do
action :install
end
It successfully sets up the repo and installs the latest version:
* pdns_recursor_install_rhel[pdns-recursor] action install
* yum_package[epel-release] action install (skipped due to only_if)
* yum_repository[powerdns-rec-40] action create
* template[/etc/yum.repos.d/powerdns-rec-40.repo] action create (up to date)
* execute[yum clean metadata powerdns-rec-40] action nothing (skipped due to action :nothing)
* execute[yum-makecache-powerdns-rec-40] action nothing (skipped due to action :nothing)
* ruby_block[yum-cache-reload-powerdns-rec-40] action nothing (skipped due to action :nothing)
(up to date)
* yum_repository[powerdns-rec-40-debuginfo] action create
* template[/etc/yum.repos.d/powerdns-rec-40-debuginfo.repo] action create (up to date)
* execute[yum clean metadata powerdns-rec-40-debuginfo] action nothing (skipped due to action :nothing)
* execute[yum-makecache-powerdns-rec-40-debuginfo] action nothing (skipped due to action :nothing)
* ruby_block[yum-cache-reload-powerdns-rec-40-debuginfo] action nothing (skipped due to action :nothing)
(up to date)
* yum_package[pdns-recursor] action install
- install version 4.0.4-1pdns.el7 of package pdns-recursor
By default the installer puts the config in /etc/pdns-recursor:
# ls -l /etc/pdns-recursor/
total 12
-rw-r--r-- 1 root root 12089 Jan 13 03:41 recursor.conf
By default the installer sets up a systemd service that expects to find the config in the default location:
# systemctl cat pdns-recursor.service
# /usr/lib/systemd/system/pdns-recursor.service
[Unit]
Description=PowerDNS Recursor
Documentation=man:pdns_recursor(1) man:rec_control(1)
Documentation=https://doc.powerdns.com
Wants=network-online.target nss-lookup.target
Before=nss-lookup.target
After=network-online.target
[Service]
Type=notify
ExecStart=/usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslog
Restart=on-failure
StartLimitInterval=0
PrivateTmp=true
PrivateDevices=true
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_CHOWN CAP_SYS_CHROOT
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
LimitNOFILE=4200
[Install]
WantedBy=multi-user.target
By default, when the service runs it creates this default socket file:
# ls -l /var/run/p*
srwxr-xr-x 1 root pdns-recursor 0 May 30 10:09 /var/run/pdns_recursor.controlsocket
The pdns_recursor_config LWRP creates a different default config location, adding an instance_dir and instance_name to the path.
In order to support CentOS 7 I think the default systemd service that is setup during the install above needs to be edited to point to the correct path that is created in the config LWRP? Rather than attempting to create a separate SysVInit service which conflicts with the default systemd service that gets created.
Maybe with this resource? https://docs.chef.io/resource_systemd_unit.html
Again....I can possibly help with a PR, but just not sure which direction the developers here want to go.
Install: I use the pdns-recursor-install LWRP from this cookbook.
Config: I'm currently using a template in my wrapper cookbook to update the default config at /etc/pdns-recursor/recursor.conf.
template '/etc/pdns-recursor/recursor.conf' do
source 'recursor.conf.erb'
owner 'root'
group 'root'
mode 00644
end
Service: Just using the default systemd service created by the installer.
Hello,
We're currently looking at using PowerDNS for our internal DNS needs. When getting a wrapper cookbook created and tested I noticed that our monitoring agent, telegraf, did not have read access to the PowerDNS control socket, which it needs in order to grab metrics. My first thought was to add the telegraf
user to the pdns
unix group, but it looks like this cookbook strictly controls[0] the membership of the group, so all changes are added and removed in a single chef run.
What we ended up doing was setting the setgid
directive to telegraf
, which seems to work, although I think it would be cleaner if we were allowed to append members to the pdns
group.
I can get a PR going for this change if you would like, but I wanted to discuss the idea or any alternatives before doing so.
Thank you!
0 - https://github.com/dnsimple/chef-pdns/blob/master/resources/pdns_authoritative_config.rb#L66
The current cookbook design restricts to the centos platform. Extending this to support RHEL with CentOS by changing platform
to `platform_family in a few areas.
This will rectify the following sort of error on RedHat I believe:
x.x.x.x ================================================================================
x.x.x.x Recipe Compile Error in /var/chef/cache/cookbooks/wrapper_ckbk/recipes/default.rb
x.x.x.x ================================================================================
x.x.x.x
x.x.x.x Chef::Exceptions::NoSuchResourceType
x.x.x.x ------------------------------------
x.x.x.x Cannot find a resource for pdns_authoritative_install on redhat version 7.4
x.x.x.x
x.x.x.x Cookbook Trace:
x.x.x.x ---------------
x.x.x.x /var/chef/cache/cookbooks/wrapper_ckbk/recipes/package.rb:24:in `from_file'
x.x.x.x /var/chef/cache/cookbooks/wrapper_ckbk/recipes/default.rb:19:in `from_file'
x.x.x.x
x.x.x.x Relevant File Content:
x.x.x.x ----------------------
x.x.x.x /var/chef/cache/cookbooks/wrapper_ckbk/recipes/package.rb:
x.x.x.x
x.x.x.x 17: # limitations under the License.
x.x.x.x 18:
x.x.x.x 19: package 'bind-utils' do
x.x.x.x 20: action :install
x.x.x.x 21: only_if { node['platform_family'] == 'rhel' }
x.x.x.x 22: end
x.x.x.x 23:
x.x.x.x 24>> pdns_authoritative_install node['wrapper_ckbk']['pdns_service'] do
x.x.x.x 25: action node['wrapper_ckbk']['role'] == 'authoritative' ? 'install'.to_sym : 'uninstall'.to_sym
x.x.x.x 26: end
x.x.x.x 27:
x.x.x.x 28: pdns_recursor_install node['wrapper_ckbk']['pdns_service'] do
x.x.x.x 29: action node['wrapper_ckbk']['role'] == 'recursor' ? 'install'.to_sym : 'uninstall'.to_sym
x.x.x.x 30: end
x.x.x.x 31:
x.x.x.x
x.x.x.x System Info:
x.x.x.x ------------
x.x.x.x chef_version=13.8.3
x.x.x.x platform=redhat
x.x.x.x platform_version=7.4
x.x.x.x ruby=ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-linux]
x.x.x.x program_name=chef-client worker: ppid=4447;start=22:19:03;
x.x.x.x executable=/opt/chef/bin/chef-client
x.x.x.x
x.x.x.x
x.x.x.x Running handlers:
x.x.x.x [2018-03-09T22:19:07+00:00] ERROR: Running exception handlers
x.x.x.x Running handlers complete
x.x.x.x [2018-03-09T22:19:07+00:00] ERROR: Exception handlers complete
x.x.x.x Chef Client failed. 0 resources updated in 03 seconds
x.x.x.x [2018-03-09T22:19:07+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
x.x.x.x [2018-03-09T22:19:07+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
x.x.x.x [2018-03-09T22:19:07+00:00] ERROR: Cannot find a resource for pdns_authoritative_install on redhat version 7.4
x.x.x.x [2018-03-09T22:19:07+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Currently, if you are upgrading authoritive on debian platforms it will crash the chef run because any back ends need to be the same version as the pnds-server or you will get library load errors when the pdns deb package automatically restarts pdns on install.
One solution is to make the install resources take the back ends you want installed along side powerdns so it can install them in the same apt_package resource, (or in one BEFORE the pdns-server) so the correct library is always in place when the resource restarts
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.