You get so used to yum upgrades going so smoothly but I learned the hard way to always make a thorough inspection after a yum update. I let yum go ahead and upgrade from 3.5 to 3.6. Afterwards I made some basic queries to httpd, postfix and bind named (probably a cached query). I even checked the /var/named/ directory and saw all my hosts files.
So looked like another smooth ride, well until today I noticed my domains dropped off the net. Too bad I did not check the bind gui or look at /etc/named.conf after the yum update since it was replaced with a generic version from 3.6.
Luckily I copied /etc/named.conf-rpmsave to named.conf and I am back in business, well at least in 24 to 72 hours for the rest of the world :(
__________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
Michael Rock mikerocks65@yahoo.com wrote:
So looked like another smooth ride, well until today I noticed my domains dropped off the net. Too bad I did not check the bind gui or look at /etc/named.conf after the yum update since it was replaced with a generic version from 3.6. Luckily I copied /etc/named.conf-rpmsave to named.conf and I am back in business, well at least in 24 to 72 hours for the rest of the world :(
Has nothing to do with YUM. It has to do with RPM.
If the changes in a package are significant enough, then any existing configuration files are renamed ".rpmsave" and new ones take their place.
If the changes are not significant enough that the existing configuration files will work, the new ones are added with ".rpmnew".
This is how it has been for a long, long time in the RHL world.
Now I agree you should _never_ see this out of a RHEL/CentOS update. That's the whole purpose of backporting changes in RHEL/CentOS updates -- to _avoid_ this from every occurring.
But apparently it did.
On 11/15/05, Bryan J. Smith thebs413@earthlink.net wrote:
Michael Rock mikerocks65@yahoo.com wrote:
So looked like another smooth ride, well until today I noticed my domains dropped off the net. Too bad I did not check the bind gui or look at /etc/named.conf after the yum update since it was replaced with a generic version from 3.6. Luckily I copied /etc/named.conf-rpmsave to named.conf and I am back in business, well at least in 24 to 72 hours for the rest of the world :(
Has nothing to do with YUM. It has to do with RPM.
Close. It has to do with RH policy.
Now I agree you should _never_ see this out of a RHEL/CentOS update. That's the whole purpose of backporting changes in RHEL/CentOS updates -- to _avoid_ this from every occurring.
RHEL tries. the named.conf file says to not edit it, and to use named.custom. Some people don't follow the directions. see bugs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145094 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145244
But apparently it did.
And it will continue to for as long as people do what redhat perceives as the "wrong" thing.
Yes this post is mostly a dupe of what I just posted under the original thread. People keep changing subjects and choking gmail.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
Jim Perrin jperrin@gmail.com wrote:
Close. It has to do with RH policy. ... RHEL tries. the named.conf file says to not edit it, and to use named.custom. Some people don't follow the directions.
see
bugs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145094 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145244
Yep, a policy I was ignorant of until now. Thanx for setting my straight.
And it will continue to for as long as people do what redhat perceives as the "wrong" thing.
The "wrong" thing is something that you'll _rarely_ ever see me say. I'm more than ready to point at my own ignorance than anything, such as in this case.
Yes this post is mostly a dupe of what I just posted under the original thread. People keep changing subjects and
choking
gmail.
Actually, GMail is the problem -- it should track based on Message-ID. Subject tracking has _never_ been a viable solution.
30+ years of SMTP/NNTP Message-ID header tracking, yet Google thinks it knows better. My posts thread correctly in the archives which, ironically, most people find via Google. How? Again, Message-ID.
Even more ironic is that appending or changing the subject has _always_ been _encouraged_ in discussion lists -- UseNet or e-mail. Because after dozens of posts, it's a major PITA to have to read everything just to find one thing. Appending or changing the subject as appropriate has always been encouraged for such threaded lists/groups.
I get thanks for doing so from people who find my posts in Google searches almost daily. Because they don't have to read through 30+ posts of the exact same subject (let alone some where the topics have changed) just to find the answer.
GMail needs to get with the program. But they won't. That's why Yahoo takes the awards, because Google doesn't track Message-ID.
I assume the significant changes were for ip6 since other than adding a location for the dump and statistics file, it adds these 3 zones which looks like they are all for ip6 support. Since I am not using ip6 and do not know anyone who is yet I assume it is safe to leave these out.
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN { type master; file "named.ip6.local"; allow-update { none; }; };
zone "255.in-addr.arpa" IN { type master; file "named.broadcast"; allow-update { none; }; };
zone "0.in-addr.arpa" IN { type master; file "named.zero"; allow-update { none; }; };
--- "Bryan J. Smith" thebs413@earthlink.net wrote:
Has nothing to do with YUM. It has to do with RPM.
If the changes in a package are significant enough, then any existing configuration files are renamed ".rpmsave" and new ones take their place.
If the changes are not significant enough that the existing configuration files will work, the new ones are added with ".rpmnew".
This is how it has been for a long, long time in the RHL world.
Now I agree you should _never_ see this out of a RHEL/CentOS update. That's the whole purpose of backporting changes in RHEL/CentOS updates -- to _avoid_ this from every occurring.
But apparently it did.
-- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On Tue, 15 Nov 2005, Bryan J. Smith wrote:
Has nothing to do with YUM. It has to do with RPM.
buzz -- wrong - thanks for playing -- It has to do with the rpm packager's design decisions; nothing more, nothing less --
rpm did just what it was told to do.
-- Russ Herrold
Bryan J. Smith wrote:
Has nothing to do with YUM. It has to do with RPM.
R P Herrold got mid-anal on BS:
buzz -- wrong - thanks for playing -- It has to do with the rpm packager's design decisions; nothing more, nothing less rpm did just what it was told to do.
Umm, isn't that what I said?
The RPM is built to either replace an existing config (renaming the existing as .rpmsave) or put out a copy of a new config (not touching the existing, calling the new .rpmnew).
I'm kinda confused on how I was "wrong"???
Bryan J. Smith wrote on Tue, 15 Nov 2005 11:48:52 -0800 (PST):
If the changes in a package are significant enough, then any existing configuration files are renamed ".rpmsave" and new ones take their place.
Any existing config files unless they haven't been changed? I think if you still have the default files they just get overwritten.
Kai
On 11/15/05, Michael Rock mikerocks65@yahoo.com wrote:
You get so used to yum upgrades going so smoothly but I learned the hard way to always make a thorough inspection after a yum update. I let yum go ahead and upgrade from 3.5 to 3.6. Afterwards I made some basic queries to httpd, postfix and bind named (probably a cached query). I even checked the /var/named/ directory and saw all my hosts files.
So looked like another smooth ride, well until today I noticed my domains dropped off the net. Too bad I did not check the bind gui or look at /etc/named.conf after the yum update since it was replaced with a generic version from 3.6.
Luckily I copied /etc/named.conf-rpmsave to named.conf and I am back in business, well at least in 24 to 72 hours for the rest of the world :(
You mean the named.conf file that tells you to use named.custom instead? This has been filed with RH several times as a bug, and has been closed repeatedly as NOTABUG. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145244 or https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145094 for more details.
Whether you agree with it or not, it appears to be how RH will do things for the forseeable future.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
--- Jim Perrin jperrin@gmail.com wrote:
You mean the named.conf file that tells you to use named.custom instead?
I do not have that comment in the named.conf files on the boxes I have. But I do see a comment in named.custom. Perhaps webmin removed the comment in named.conf, which I suppose also manages bind incorrectly for Redhat since it edits named.conf directly.
This has been filed with RH several times as a bug, and has been closed repeatedly as NOTABUG. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145244
or
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145094
for more details.
Whether you agree with it or not, it appears to be how RH will do things for the forseeable future.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
} Michael Rock wrote: } } You get so used to yum upgrades going so smoothly but } I learned the hard way to always make a thorough } inspection after a yum update. I let yum go ahead and } upgrade from 3.5 to 3.6. Afterwards I made some basic } queries to httpd, postfix and bind named (probably a } cached query). I even checked the /var/named/ } directory and saw all my hosts files. } } So looked like another smooth ride, well until today I } noticed my domains dropped off the net. Too bad I did } not check the bind gui or look at /etc/named.conf } after the yum update since it was replaced with a } generic version from 3.6. } } Luckily I copied /etc/named.conf-rpmsave to named.conf } and I am back in business, well at least in 24 to 72 } hours for the rest of the world :( }
interesting, on a CentOS 4.1 chroot nameserver i did a
yum upgrade yum
"only" here some time ago and did not experience this issue.
i have not done any upgrades since 4.2 was released other than the yum upgrade though.
this is just FYI
- rh
-- Robert Hanson - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
On Tue, 2005-11-15 at 12:15 -0800, Robert wrote:
} Michael Rock wrote: } } You get so used to yum upgrades going so smoothly but } I learned the hard way to always make a thorough } inspection after a yum update. I let yum go ahead and } upgrade from 3.5 to 3.6. Afterwards I made some basic } queries to httpd, postfix and bind named (probably a } cached query). I even checked the /var/named/ } directory and saw all my hosts files. } } So looked like another smooth ride, well until today I } noticed my domains dropped off the net. Too bad I did } not check the bind gui or look at /etc/named.conf } after the yum update since it was replaced with a } generic version from 3.6. } } Luckily I copied /etc/named.conf-rpmsave to named.conf } and I am back in business, well at least in 24 to 72 } hours for the rest of the world :( }
interesting, on a CentOS 4.1 chroot nameserver i did a
yum upgrade yum
"only" here some time ago and did not experience this issue.
i have not done any upgrades since 4.2 was released other than the yum upgrade though.
this is just FYI
- rh
-- Robert Hanson - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
Ok guys ... this is ONLY an issue IF you have caching-nameserver AND bind installed ... and if you used the named.conf from caching- nameserver.
RH says to NOT install caching-nameserver and a real name server on the same machine ...
When caching-nameserver is upgraded, it changes your named.conf file ... to make it, guess what, a caching nameserver. (A caching name server is one that resolves all domains ... but is not the master or secondary for any zones).
This is the exactly expected and designed behavior ... so, NEVER, EVER, EVER install caching-nameserver on a DNS server that your are using for real domain control.
Ok guys ... this is ONLY an issue IF you have caching-nameserver AND bind installed ... and if you used the named.conf from caching- nameserver.
RH says to NOT install caching-nameserver and a real name server on the same machine ...
Excuse my ignorance on this subject, been looking for a link that explains the policy and why? Right now I have primary and secondary name servers hosting many domains and web server applications that need to resolve DNS from these servers. Then I have a handful of workstations that use these servers for regular DNS queries.
This will be significant work/expense and to find space for it just to separate the caching name server to a separate box just so the stations can have DNS queries.
Been doing it this way for years without a problem, so any info you can pass on.
When caching-nameserver is upgraded, it changes your named.conf file ... to make it, guess what, a caching nameserver. (A caching name server is one that resolves all domains ... but is not the master or secondary for any zones).
This is the exactly expected and designed behavior ... so, NEVER, EVER, EVER install caching-nameserver on a DNS server that your are using for real domain control.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On 11/15/05, Michael Rock mikerocks65@yahoo.com wrote:
Ok guys ... this is ONLY an issue IF you have caching-nameserver AND bind installed ... and if you used the named.conf from caching- nameserver.
RH says to NOT install caching-nameserver and a real name server on the same machine ...
Excuse my ignorance on this subject, been looking for a link that explains the policy and why? Right now I have primary and secondary name servers hosting many domains and web server applications that need to resolve DNS from these servers. Then I have a handful of workstations that use these servers for regular DNS queries.
This will be significant work/expense and to find space for it just to separate the caching name server to a separate box just so the stations can have DNS queries.
Been doing it this way for years without a problem, so any info you can pass on.
Best documentation I can find is from one a redhatter who closed one of the caching-nameserver issues as not-a-bug. his explanation follows thusly:
This is not an issue with the bind-* package, but with the caching-nameserver package.
No bind-* package supplies any named configuration files, unless none exist on the system, when only rndc.conf, rndc.key, and the bare minimum named.conf sufficient to allow named to run are installed.
When you install the 'caching-nameserver' package, which consists entirely of the named configuration files, you are asking for a caching-nameserver named configuration to be installed.
If you want to customize your named configuration files, and run something other / more than a caching-only nameserver, uninstall the caching-nameserver package.
Unless caching-nameserver replaces any existing named configuration files on installation / upgrade, there would be no way of guaranteeing after installation that a caching-nameserver was in place afterwards, and no way of upgrading these configuration files.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
Thanks Jim but you already established that in the links you posted. I was asking him why he writes never never put both caching and bind on the same box.
I posted my configuration below so it just seems like resource and expense overkill to setup a separate box just for DNS queries, rather than make use of the two bind servers.
--- Jim Perrin jperrin@gmail.com wrote:
On 11/15/05, Michael Rock mikerocks65@yahoo.com wrote:
Ok guys ... this is ONLY an issue IF you have caching-nameserver AND bind installed ... and if you used the
named.conf
from caching- nameserver.
RH says to NOT install caching-nameserver and a
real
name server on the same machine ...
Excuse my ignorance on this subject, been looking
for
a link that explains the policy and why? Right
now I
have primary and secondary name servers hosting
many
domains and web server applications that need to resolve DNS from these servers. Then I have a
handful
of workstations that use these servers for regular
DNS
queries.
This will be significant work/expense and to find space for it just to separate the caching name
server
to a separate box just so the stations can have
DNS
queries.
Been doing it this way for years without a
problem, so
any info you can pass on.
Best documentation I can find is from one a redhatter who closed one of the caching-nameserver issues as not-a-bug. his explanation follows thusly:
This is not an issue with the bind-* package, but with the caching-nameserver package.
No bind-* package supplies any named configuration files, unless none exist on the system, when only rndc.conf, rndc.key, and the bare minimum named.conf sufficient to allow named to run are installed.
When you install the 'caching-nameserver' package, which consists entirely of the named configuration files, you are asking for a caching-nameserver named configuration to be installed.
If you want to customize your named configuration files, and run something other / more than a caching-only nameserver, uninstall the caching-nameserver package.
Unless caching-nameserver replaces any existing named configuration files on installation / upgrade, there would be no way of guaranteeing after installation that a caching-nameserver was in place afterwards, and no way of upgrading these configuration files.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
the caching-nameserver package which is the root of the problem should perhaps better be called 'only-caching-nameserver-and-nothing-else'. You install it if you don't feel like configuring anything and want a local caching nameserver on a desktop.
If you want to configure a server with DNS, then you DO NOT install caching-nameserver, instead you setup bind by hand (or with a different program GUI whatever) and you can configure it to host some zones and to query others from the internet and to reply to some queries from local hosts (local LAN) recursively and to only reply to hosted zone queries from non-local hosts (rest of the Internet). Etc. IE. YOU DO NOT NEED THE CACHING-NAMESERVER PACKAGE TO HAVE A CACHING NAMESERVER. The package is only meant to simplify life on normal desktops.
Besides you shouldn't be running bind anyway... DJBDNS/TINYDNS/DNSCACHE are much better anyway (although a little harder to setup in the first place, once done they run and run and run like duracel or the energizer bunny with no problems whatsoever).
Cheers, MaZe.
On Tue, 15 Nov 2005, Michael Rock wrote:
Thanks Jim but you already established that in the links you posted. I was asking him why he writes never never put both caching and bind on the same box.
I posted my configuration below so it just seems like resource and expense overkill to setup a separate box just for DNS queries, rather than make use of the two bind servers.
--- Jim Perrin jperrin@gmail.com wrote:
On 11/15/05, Michael Rock mikerocks65@yahoo.com wrote:
Ok guys ... this is ONLY an issue IF you have caching-nameserver AND bind installed ... and if you used the
named.conf
from caching- nameserver.
RH says to NOT install caching-nameserver and a
real
name server on the same machine ...
Excuse my ignorance on this subject, been looking
for
a link that explains the policy and why? Right
now I
have primary and secondary name servers hosting
many
domains and web server applications that need to resolve DNS from these servers. Then I have a
handful
of workstations that use these servers for regular
DNS
queries.
This will be significant work/expense and to find space for it just to separate the caching name
server
to a separate box just so the stations can have
DNS
queries.
Been doing it this way for years without a
problem, so
any info you can pass on.
Best documentation I can find is from one a redhatter who closed one of the caching-nameserver issues as not-a-bug. his explanation follows thusly:
This is not an issue with the bind-* package, but with the caching-nameserver package.
No bind-* package supplies any named configuration files, unless none exist on the system, when only rndc.conf, rndc.key, and the bare minimum named.conf sufficient to allow named to run are installed.
When you install the 'caching-nameserver' package, which consists entirely of the named configuration files, you are asking for a caching-nameserver named configuration to be installed.
If you want to customize your named configuration files, and run something other / more than a caching-only nameserver, uninstall the caching-nameserver package.
Unless caching-nameserver replaces any existing named configuration files on installation / upgrade, there would be no way of guaranteeing after installation that a caching-nameserver was in place afterwards, and no way of upgrading these configuration files.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 2005-11-15 at 13:31 -0800, Michael Rock wrote:
Thanks Jim but you already established that in the links you posted. I was asking him why he writes never never put both caching and bind on the same box.
I posted my configuration below so it just seems like resource and expense overkill to setup a separate box just for DNS queries, rather than make use of the two bind servers.
I am trying really hard to explain it...
You have EITHER a real DNS server ... that will lookup all zones, including ones it controls ... (ie it works for both controlled zones and all the others, just like caching nameserver)
OR
You have caching-nameserver installed ... which means, you do not want to control any zones, just have a local nameserver.
SO
You don't need caching-nameserver if you have a real nameserver installed on a box.
--- Jim Perrin jperrin@gmail.com wrote:
On 11/15/05, Michael Rock mikerocks65@yahoo.com wrote:
Ok guys ... this is ONLY an issue IF you have caching-nameserver AND bind installed ... and if you used the
named.conf
from caching- nameserver.
RH says to NOT install caching-nameserver and a
real
name server on the same machine ...
Excuse my ignorance on this subject, been looking
for
a link that explains the policy and why? Right
now I
have primary and secondary name servers hosting
many
domains and web server applications that need to resolve DNS from these servers. Then I have a
handful
of workstations that use these servers for regular
DNS
queries.
This will be significant work/expense and to find space for it just to separate the caching name
server
to a separate box just so the stations can have
DNS
queries.
Been doing it this way for years without a
problem, so
any info you can pass on.
Best documentation I can find is from one a redhatter who closed one of the caching-nameserver issues as not-a-bug. his explanation follows thusly:
This is not an issue with the bind-* package, but with the caching-nameserver package.
No bind-* package supplies any named configuration files, unless none exist on the system, when only rndc.conf, rndc.key, and the bare minimum named.conf sufficient to allow named to run are installed.
When you install the 'caching-nameserver' package, which consists entirely of the named configuration files, you are asking for a caching-nameserver named configuration to be installed.
If you want to customize your named configuration files, and run something other / more than a caching-only nameserver, uninstall the caching-nameserver package.
Unless caching-nameserver replaces any existing named configuration files on installation / upgrade, there would be no way of guaranteeing after installation that a caching-nameserver was in place afterwards, and no way of upgrading these configuration files.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 2005-11-15 at 13:14 -0800, Michael Rock wrote:
Ok guys ... this is ONLY an issue IF you have caching-nameserver AND bind installed ... and if you used the named.conf from caching- nameserver.
RH says to NOT install caching-nameserver and a real name server on the same machine ...
Excuse my ignorance on this subject, been looking for a link that explains the policy and why? Right now I have primary and secondary name servers hosting many domains and web server applications that need to resolve DNS from these servers. Then I have a handful of workstations that use these servers for regular DNS queries.
This will be significant work/expense and to find space for it just to separate the caching name server to a separate box just so the stations can have DNS queries.
Been doing it this way for years without a problem, so any info you can pass on.
A real name server doesn't also need caching-nameserver installed ... it will lookup zones it doesn't control.
caching-nameserver is what you would install if you didn't need to control any domains and wanted a local DNS server.
caching-nameserver is just bind and some config files that don't have any zones in the named.conf file
If you install caching-nameserver you are saying that you want a DNS machine that doesn't control zones.
If you remove the package caching-nameserver, it will save your named.custom and named.conf files as rpmsave files ... just move them back into place afterwards and leave caching-nameserver removed.
I am sure I never specifically installed the caching name server but a rpm -q caching-nameserver yields version 7.3-3_EL3.
I usually just select the DNS option during the GUI install and look to make sure bind is listed (perhaps the caching name server is automatically checked). There after I ended up editing the named.conf or used webmin that in turn edited the named.conf.
So ultimately I some how ended up with a caching name server I do not need. So if I got this right
1. remove rpm -e caching-nameserver 2. copy my zones from named.conf-rpmsave to named.custom 3. do not use webmin since it edits named.conf or reconfigure it to edit named.custom
Should anything be specifically removed from named.conf or named.custom having to do with the caching name server?
Did I miss anything here?
Thanks guys.
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
A real name server doesn't also need
caching-nameserver installed ... it will lookup zones it doesn't control.
caching-nameserver is what you would install if you didn't need to control any domains and wanted a local DNS server.
caching-nameserver is just bind and some config files that don't have any zones in the named.conf file
If you install caching-nameserver you are saying that you want a DNS machine that doesn't control zones.
If you remove the package caching-nameserver, it will save your named.custom and named.conf files as rpmsave files ... just move them back into place afterwards and leave caching-nameserver removed.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
On Tue, 2005-11-15 at 13:47 -0800, Michael Rock wrote:
I am sure I never specifically installed the caching name server but a rpm -q caching-nameserver yields version 7.3-3_EL3.
I usually just select the DNS option during the GUI install and look to make sure bind is listed (perhaps the caching name server is automatically checked). There after I ended up editing the named.conf or used webmin that in turn edited the named.conf.
So ultimately I some how ended up with a caching name server I do not need. So if I got this right
- remove rpm -e caching-nameserver
- copy my zones from named.conf-rpmsave to
named.custom 3. do not use webmin since it edits named.conf or reconfigure it to edit named.custom
Should anything be specifically removed from named.conf or named.custom having to do with the caching name server?
named.conf is OK for the config file ... it won't get changed on future updates
Did I miss anything here?
Thanks guys.
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
A real name server doesn't also need
caching-nameserver installed ... it will lookup zones it doesn't control.
caching-nameserver is what you would install if you didn't need to control any domains and wanted a local DNS server.
caching-nameserver is just bind and some config files that don't have any zones in the named.conf file
If you install caching-nameserver you are saying that you want a DNS machine that doesn't control zones.
If you remove the package caching-nameserver, it will save your named.custom and named.conf files as rpmsave files ... just move them back into place afterwards and leave caching-nameserver removed.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I went ahead and removed the caching name server. Panic set in when bind would not load until I realized it also renames /var/named/named.ca and named.local. After renaming them and setting owner/group back to named it works fine.
Thanks
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
Should anything be specifically removed from named.conf or named.custom having to do with the caching name server?
named.conf is OK for the config file ... it won't get changed on future updates
__________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
On Tue, 2005-11-15 at 16:26 -0600, Johnny Hughes wrote:
On Tue, 2005-11-15 at 13:47 -0800, Michael Rock wrote:
I am sure I never specifically installed the caching name server but a rpm -q caching-nameserver yields version 7.3-3_EL3.
I usually just select the DNS option during the GUI install and look to make sure bind is listed (perhaps the caching name server is automatically checked). There after I ended up editing the named.conf or used webmin that in turn edited the named.conf.
So ultimately I some how ended up with a caching name server I do not need. So if I got this right
- remove rpm -e caching-nameserver
- copy my zones from named.conf-rpmsave to
named.custom 3. do not use webmin since it edits named.conf or reconfigure it to edit named.custom
Should anything be specifically removed from named.conf or named.custom having to do with the caching name server?
named.conf is OK for the config file ... it won't get changed on future updates
Did I miss anything here?
Thanks guys.
---- probably a bugzilla entry to upstream provider to maybe create an 'artificial' conflict between the 2 packages so that you can't install both accidentally.
Craig
On Tue, 2005-11-15 at 15:47 -0700, Craig White wrote:
On Tue, 2005-11-15 at 16:26 -0600, Johnny Hughes wrote:
On Tue, 2005-11-15 at 13:47 -0800, Michael Rock wrote:
I am sure I never specifically installed the caching name server but a rpm -q caching-nameserver yields version 7.3-3_EL3.
I usually just select the DNS option during the GUI install and look to make sure bind is listed (perhaps the caching name server is automatically checked). There after I ended up editing the named.conf or used webmin that in turn edited the named.conf.
So ultimately I some how ended up with a caching name server I do not need. So if I got this right
- remove rpm -e caching-nameserver
- copy my zones from named.conf-rpmsave to
named.custom 3. do not use webmin since it edits named.conf or reconfigure it to edit named.custom
Should anything be specifically removed from named.conf or named.custom having to do with the caching name server?
named.conf is OK for the config file ... it won't get changed on future updates
Did I miss anything here?
Thanks guys.
probably a bugzilla entry to upstream provider to maybe create an 'artificial' conflict between the 2 packages so that you can't install both accidentally.
caching-nameserver is just the config files ... it requires bind to be installed too
On Tue, 2005-11-15 at 16:59 -0600, Johnny Hughes wrote:
On Tue, 2005-11-15 at 15:47 -0700, Craig White wrote:
probably a bugzilla entry to upstream provider to maybe create an 'artificial' conflict between the 2 packages so that you can't install both accidentally.
caching-nameserver is just the config files ... it requires bind to be installed too
---- given the fact that the result of an update breaks working configurations and avoiding that situation is one of the targets of the upstream provider, the upstream provider probably should invest a little bit of time/energy to ensure that this is unlikely to occur.
Given there are idiot admins like me who rarely miss an opportunity to step on their d*cks...(I think I only got caught on this once but never knew until now, why that was the case).
Craig
Craig White wrote:
caching-nameserver is just the config files ... it requires bind to be installed too
given the fact that the result of an update breaks working configurations and avoiding that situation is one of the targets of the upstream provider, the upstream provider probably should invest a little bit of time/energy to ensure that this is unlikely to occur.
Given there are idiot admins like me who rarely miss an opportunity to step on their d*cks...(I think I only got caught on this once but never knew until now, why that was the case).
Heh...that's OK. I only discovered this by accident as well. And it was only very recently...maybe 6-9 months ago...after having used RH Linux since version 4-ish.
Cheers,
If it is just config files then perhaps even though I removed the rpm it is still a caching name server since the config files are unchanged?
Can someone tell me what needs to be removed from named.conf so it is not a caching named server?
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
On Tue, 2005-11-15 at 15:47 -0700, Craig White wrote:
On Tue, 2005-11-15 at 16:26 -0600, Johnny Hughes
wrote:
On Tue, 2005-11-15 at 13:47 -0800, Michael Rock
wrote:
I am sure I never specifically installed the
caching
name server but a rpm -q caching-nameserver
yields
version 7.3-3_EL3.
I usually just select the DNS option during
the GUI
install and look to make sure bind is listed
(perhaps
the caching name server is automatically
checked).
There after I ended up editing the named.conf
or used
webmin that in turn edited the named.conf.
So ultimately I some how ended up with a
caching name
server I do not need. So if I got this right
- remove rpm -e caching-nameserver
- copy my zones from named.conf-rpmsave to
named.custom 3. do not use webmin since it edits named.conf
or
reconfigure it to edit named.custom
Should anything be specifically removed from named.conf or named.custom having to do with
the
caching name server?
named.conf is OK for the config file ... it
won't get changed on future
updates
Did I miss anything here?
Thanks guys.
probably a bugzilla entry to upstream provider to
maybe create an
'artificial' conflict between the 2 packages so
that you can't install
both accidentally.
caching-nameserver is just the config files ... it requires bind to be installed too
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
I don't think it's a matter of what needs to be removed, but rather what needs to be added - zone declarations need to be added both in the main configuration file and their respective files...
Cheers, MaZe.
On Tue, 15 Nov 2005, Michael Rock wrote:
If it is just config files then perhaps even though I removed the rpm it is still a caching name server since the config files are unchanged?
Can someone tell me what needs to be removed from named.conf so it is not a caching named server?
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
On Tue, 2005-11-15 at 15:47 -0700, Craig White wrote:
On Tue, 2005-11-15 at 16:26 -0600, Johnny Hughes
wrote:
On Tue, 2005-11-15 at 13:47 -0800, Michael Rock
wrote:
I am sure I never specifically installed the
caching
name server but a rpm -q caching-nameserver
yields
version 7.3-3_EL3.
I usually just select the DNS option during
the GUI
install and look to make sure bind is listed
(perhaps
the caching name server is automatically
checked).
There after I ended up editing the named.conf
or used
webmin that in turn edited the named.conf.
So ultimately I some how ended up with a
caching name
server I do not need. So if I got this right
- remove rpm -e caching-nameserver
- copy my zones from named.conf-rpmsave to
named.custom 3. do not use webmin since it edits named.conf
or
reconfigure it to edit named.custom
Should anything be specifically removed from named.conf or named.custom having to do with
the
caching name server?
named.conf is OK for the config file ... it
won't get changed on future
updates
Did I miss anything here?
Thanks guys.
probably a bugzilla entry to upstream provider to
maybe create an
'artificial' conflict between the 2 packages so
that you can't install
both accidentally.
caching-nameserver is just the config files ... it requires bind to be installed too
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--- Maciej ¯enczykowski maze@cela.pl wrote:
These may sound like really simple questions but I am questioning my basic beliefs since just learning now that for years I have been incorrectly configuring bind through named.conf and just found out I had a caching-dns rpm installed but did not know it.
I don't think it's a matter of what needs to be removed, but rather what needs to be added - zone declarations need to be added both in the main configuration file and their respective files...
But if that is the case and the rpm is just configuration files it would seem I was not running a caching-name server after all.
Other than my domains nothing here is related to the caching-dns server? I need named.ca so my primary can contact root servers and localhost is normal correct?
controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; zone "." { type hint; file "named.ca"; }; zone "localhost" { allow-update { none; }; type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" { allow-update { none; }; type master; file "named.local"; };
Cheers, MaZe.
On Tue, 15 Nov 2005, Michael Rock wrote:
If it is just config files then perhaps even
though I
removed the rpm it is still a caching name server since the config files are unchanged?
Can someone tell me what needs to be removed from named.conf so it is not a caching named server?
--- Johnny Hughes mailing-lists@hughesjr.com
wrote:
On Tue, 2005-11-15 at 15:47 -0700, Craig White wrote:
On Tue, 2005-11-15 at 16:26 -0600, Johnny Hughes
wrote:
On Tue, 2005-11-15 at 13:47 -0800, Michael Rock
wrote:
I am sure I never specifically installed the
caching
name server but a rpm -q caching-nameserver
yields
version 7.3-3_EL3.
I usually just select the DNS option during
the GUI
install and look to make sure bind is listed
(perhaps
the caching name server is automatically
checked).
There after I ended up editing the named.conf
or used
webmin that in turn edited the named.conf.
So ultimately I some how ended up with a
caching name
server I do not need. So if I got this right
- remove rpm -e caching-nameserver
- copy my zones from named.conf-rpmsave to
named.custom 3. do not use webmin since it edits named.conf
or
reconfigure it to edit named.custom
Should anything be specifically removed from named.conf or named.custom having to do with
the
caching name server?
named.conf is OK for the config file ... it
won't get changed on future
updates
Did I miss anything here?
Thanks guys.
probably a bugzilla entry to upstream provider
to
maybe create an
'artificial' conflict between the 2 packages so
that you can't install
both accidentally.
caching-nameserver is just the config files ...
it
requires bind to be installed too
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Yahoo! FareChase: Search multiple travel sites in
one click.
http://farechase.yahoo.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
Am Dienstag, den 15.11.2005, 15:58 -0800 schrieb Michael Rock:
--- Maciej ¯enczykowski maze@cela.pl wrote:
But if that is the case and the rpm is just configuration files it would seem I was not running a caching-name server after all.
Other than my domains nothing here is related to the caching-dns server? I need named.ca so my primary can contact root servers and localhost is normal correct?
A DNS-server which is configured to do recursion to the root servers is considered a "caching nameserver" as it looks up the information from the real servers and caches the replies locally. So everyone with a .-zone in named.conf actually runs a caching nameserver.
Regards, Andreas
On Tue, 2005-11-15 at 15:23 -0800, Michael Rock wrote:
If it is just config files then perhaps even though I removed the rpm it is still a caching name server since the config files are unchanged?
Can someone tell me what needs to be removed from named.conf so it is not a caching named server?
You are now good to go ... since caching-nameserver is not installed anymore, it will not get updated.
SO ... it won't re-write your config files and you will live happily ever after
There was nothing wrong with your config files before ... just when caching-nameserver is installed, you can't manually update the config files because they will get replaced on the next caching-nameserver update.
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
On Tue, 2005-11-15 at 15:47 -0700, Craig White wrote:
On Tue, 2005-11-15 at 16:26 -0600, Johnny Hughes
wrote:
On Tue, 2005-11-15 at 13:47 -0800, Michael Rock
wrote:
I am sure I never specifically installed the
caching
name server but a rpm -q caching-nameserver
yields
version 7.3-3_EL3.
I usually just select the DNS option during
the GUI
install and look to make sure bind is listed
(perhaps
the caching name server is automatically
checked).
There after I ended up editing the named.conf
or used
webmin that in turn edited the named.conf.
So ultimately I some how ended up with a
caching name
server I do not need. So if I got this right
- remove rpm -e caching-nameserver
- copy my zones from named.conf-rpmsave to
named.custom 3. do not use webmin since it edits named.conf
or
reconfigure it to edit named.custom
Should anything be specifically removed from named.conf or named.custom having to do with
the
caching name server?
named.conf is OK for the config file ... it
won't get changed on future
updates
Did I miss anything here?
Thanks guys.
probably a bugzilla entry to upstream provider to
maybe create an
'artificial' conflict between the 2 packages so
that you can't install
both accidentally.
caching-nameserver is just the config files ... it requires bind to be installed too
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ok just saw this, then ignore my last post. So it does not come back if it ever gets updated is 'yum clean all' sufficient.
The reason I ask is there is so much stuff I have gotten rid of in the last year and always seems to come back. For example cups and linux printing rpms. I must have removed them so many times in the last year from these boxes.
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
On Tue, 2005-11-15 at 15:23 -0800, Michael Rock wrote:
If it is just config files then perhaps even
though I
removed the rpm it is still a caching name server since the config files are unchanged?
Can someone tell me what needs to be removed from named.conf so it is not a caching named server?
You are now good to go ... since caching-nameserver is not installed anymore, it will not get updated.
SO ... it won't re-write your config files and you will live happily ever after
There was nothing wrong with your config files before ... just when caching-nameserver is installed, you can't manually update the config files because they will get replaced on the next caching-nameserver update.
--- Johnny Hughes mailing-lists@hughesjr.com
wrote:
On Tue, 2005-11-15 at 15:47 -0700, Craig White wrote:
On Tue, 2005-11-15 at 16:26 -0600, Johnny
Hughes
wrote:
On Tue, 2005-11-15 at 13:47 -0800, Michael
Rock
wrote:
I am sure I never specifically installed
the
caching
name server but a rpm -q
caching-nameserver
yields
version 7.3-3_EL3.
I usually just select the DNS option
during
the GUI
install and look to make sure bind is
listed
(perhaps
the caching name server is automatically
checked).
There after I ended up editing the
named.conf
or used
webmin that in turn edited the named.conf.
So ultimately I some how ended up with a
caching name
server I do not need. So if I got this
right
- remove rpm -e caching-nameserver
- copy my zones from named.conf-rpmsave
to
named.custom 3. do not use webmin since it edits
named.conf
or
reconfigure it to edit named.custom
Should anything be specifically removed
from
named.conf or named.custom having to do
with
the
caching name server?
named.conf is OK for the config file ... it
won't get changed on future
updates
Did I miss anything here?
Thanks guys.
probably a bugzilla entry to upstream provider
to
maybe create an
'artificial' conflict between the 2 packages
so
that you can't install
both accidentally.
caching-nameserver is just the config files ...
it
requires bind to be installed too
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! FareChase: Search multiple travel sites in
one click.
http://farechase.yahoo.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
__________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
Michael Rock wrote:
I am sure I never specifically installed the caching name server but a rpm -q caching-nameserver yields version 7.3-3_EL3.
I think it gets installed by default if you say you want a name server. I'm not certain since I manually exclude it during my installs.
So ultimately I some how ended up with a caching name server I do not need. So if I got this right
- remove rpm -e caching-nameserver
Yes.
- copy my zones from named.conf-rpmsave to
named.custom
Yes, that seems correct, but I've never been in your particular situation.
- do not use webmin since it edits named.conf or
reconfigure it to edit named.custom
Not sure.
Cheers,
On Tue, 2005-11-15 at 15:14, Michael Rock wrote:
RH says to NOT install caching-nameserver and a real name server on the same machine ...
Excuse my ignorance on this subject, been looking for a link that explains the policy and why? Right now I have primary and secondary name servers hosting many domains and web server applications that need to resolve DNS from these servers. Then I have a handful of workstations that use these servers for regular DNS queries.
This will be significant work/expense and to find space for it just to separate the caching name server to a separate box just so the stations can have DNS queries.
The normal bind will resolve and cache any domains where it isn't configured as a primary or slave server. You don't need a separate caching-nameserver installed for that. You would use the caching-nameserver package only when you don't have any local zones and don't need any local config changes.
Johnny Hughes mailing-lists@hughesjr.com wrote:
RH says to NOT install caching-nameserver and a real name server on the same machine ...
Nevermind then. I guess I was doing it right. I remove caching-nameserver on my DNS primary/secondary servers.
-
Andreas Rogge -
Bryan J. Smith -
Chris Mauritz -
Craig White -
Jim Perrin -
Johnny Hughes -
Kai Schaetzl -
Les Mikesell -
Maciej Żenczykowski -
Michael Rock -
R P Herrold -
Robert