Bug 57460
Summary: | rndc.conf has an error | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Zenon Mousmoulas <zmousm> |
Component: | bind | Assignee: | Bernhard Rosenkraenzer <bero> |
Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-01-23 10:46:36 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Zenon Mousmoulas
2001-12-13 01:46:29 UTC
This could be related to the updating process... Do you still see this if you uninstall and reinstall the package? What happens is the following: @KEY@ is replaced with a random key if /etc/rndc.conf.rpmnew doesn't exist (we don't want to touch an edited /etc/rndc.conf, so if /etc/rndc.conf.rpmnew exists, we assume /etc/rndc.conf was left over from your previous config and the new sample file is /etc/rndc.conf.rpmnew). I can't see anything else that would cause this to fail. Please confirm this is the problem; then I'll have to think of a new way of detecting whether or not we should mess with /etc/rndc.conf. bero wrote: @KEY@ is replaced with a random key if /etc/rndc.conf.rpmnew doesn't exist (we don't want to touch an edited /etc/rndc.conf, so if /etc/rndc.conf.rpmnew exists, we assume /etc/rndc.conf was left over from your previous config and the new sample file is /etc/rndc.conf.rpmnew). According to this, and afaik, a modified config file shouldn't be touched at all. Instead it's written to .rpmnew. Let's assume /etc/rndc.conf was modified since I don't remember anymore if it was, so the new sample config should be written ton /etc/rndc.conf.rpmnew. If I understand right, you mean my modified /etc/rndc.conf contained this "@KEY@" string as the secret in the key "rndckey" statement. That just can't be right for two reasons. First of all I don't remember finding any /etc/rndc.conf.rpmnew after upgrading to this rawhide package, but OK maybe I don't remember right. Second and most important though, rndc used to work before the upgrade (without the workarounds I noted in my original posting). So I find it rather unlikely I could have left this by accident in that file, because rndc would then also fail before the upgrade, which I am rather sure was not happenning. In any case I will uninstall bind after backing up config files and zones and reinstall; then I can answer your question. Hrm well unfortunately I can't get a copy of bind-9.2.0-1.i386.rpm anymore, or any of the other required packages in the same version, since it has been replaced in rawhide by bind-9.2.0-2. The changelog says 9.2.0-2 is just an automated rebuild so the reported behavior shouldn't have changed, but I really can't be sure about that. In any case, I uninstalled 9.2.0-1, wiped .rpmsave configs and installed bind-9.2.0- 2, and it doesn't create any erroneous rndc.conf like the one I reported. Anyway I recognize it could have been some mistake on my end, although it certainly didn't seem so at the time I reported this bug. If I did not make some mistake, I really don't know what else to think anymore. But I guess it doesn't matter anymore because the current package from rawhide installs correctly. I hope and expect it also does upgrade and freshen installations (from the bind-9.1.3-4 RHL 7.2 package) without problems too, but again I can't say for sure. I suggest you close this bug, unless you feel it requires further investigation. I would close it myself, but I am not sure which resolution is appropriate. On a final note, I noted that /etc/rndc.conf contains a key statement which is duplicated from /etc/rndc.key. /etc/named.conf includes /etc/rndc.key. I suggest that if rndc config file syntax allows include statements, then /etc/rndc.conf should also use that instead, because that would be more efficient: you would only need to change the key in one file, then both named and rndc would be instantly aware of the new key. It doesn't look like file permissions could break such a setup, since in the current setup both /etc/rndc.conf and /etc/rndc.key are only readable by users of the group named and root. I won't open a new bug for this suggestion, since it's such a minor issue. If you wanna consider it for future builds, fine, if not, np :) Again, thanks for your help. What might have happened is the following: You installed the system. You upgraded bind, which created a rndc.conf.rpmnew file You upgraded bind again, it noticed the rndc.conf.rpmnew file from the previous installation (even though it replaced rndc.conf itself), so didn't make any changes to rndc.conf after that. I agree that ideally, rndc.conf would just include rndc.key - unfortunately, at least last time I checked (9.1.2) rndc.conf didn't support include statements. I'll try again with 9.2.0. Ok, rndc.conf supports include statements in 9.2.0. Changed to use that in 9.2.0-3, making further breakages like this one impossible. OK that's right, the scenario you suggested could have happened indeed during such an upgrade process, however I only upgraded once and not twice: bind- 9.1.3-4 (RHL 7.2) to bind-9.2.0-1 (rawhide) so I still don't know how it would be possible for rpm to act like that. Nevertheless, wouldn't such a behavior be a problem in rpm? I mean the way you said it replaces /etc/rndc.conf but it doesn't proceed with variable substitutions if .rpmnew already exists? I would expect it to simply replace /etc/rndc.rpmnew and do all substitutions in that file. Thanks again for accepting my suggestion. This is my last posting here, promise :) |