Re: [CentOS] tinydns/djbdns opinion poll
Kai Schaetzl wrote: Ian Forde wrote on Wed, 11 Feb 2009 20:01:21 -0800: locate rpmsave locate rpmnew rpmsave is left from *un*installations, rpmnew is the *new* file, there is no file overwritten. rpm usually doesn't overwrite files if they got changed. AFAIK this is not correct, a package upgrade can create either of these (or both, or neither of them despite your having edited a file). And that's the way it should be, either choice can be justified. It depends on the package's SPEC file. rpm just does what it's told, everything is in the hands of the package maintainer. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Thu, Feb 12, 2009, Nicolas Thierry-Mieg wrote: Kai Schaetzl wrote: Ian Forde wrote on Wed, 11 Feb 2009 20:01:21 -0800: locate rpmsave locate rpmnew rpmsave is left from *un*installations, rpmnew is the *new* file, there is no file overwritten. rpm usually doesn't overwrite files if they got changed. AFAIK this is not correct, a package upgrade can create either of these (or both, or neither of them despite your having edited a file). And that's the way it should be, either choice can be justified. It depends on the package's SPEC file. rpm just does what it's told, everything is in the hands of the package maintainer. I think that the only time a .rpmnew file is created is if the SPEC file specifies ``%config(noreplace)'' for a file. If the ``noreplace'' option is not used, the .rpmsave files are created either when a package is removed, or when a file specified as a configuration file in the RPM SPEC file is updated and the file is sufficiently different from the default (for some definition of suffieiently). In the OpenPKG portable packaging system, which is RPM based, the presence of any .rpmnew or .rpmsave configuration files will prevent a package from starting, and warning messages will be generated until the situation is resolved. Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 The obscure we see eventually, the completely apparent takes longer. -- Edward R. Morrow ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Bill Campbell wrote: locate rpmsave locate rpmnew rpmsave is left from *un*installations, rpmnew is the *new* file, there is no file overwritten. rpm usually doesn't overwrite files if they got changed. AFAIK this is not correct, a package upgrade can create either of these (or both, or neither of them despite your having edited a file). And that's the way it should be, either choice can be justified. It depends on the package's SPEC file. rpm just does what it's told, everything is in the hands of the package maintainer. I think that the only time a .rpmnew file is created is if the SPEC file specifies ``%config(noreplace)'' for a file. If the ``noreplace'' option is not used, the .rpmsave files are created either when a package is removed, or when a file specified as a configuration file in the RPM SPEC file is updated and the file is sufficiently different from the default (for some definition of suffieiently). In the OpenPKG portable packaging system, which is RPM based, the presence of any .rpmnew or .rpmsave configuration files will prevent a package from starting, and warning messages will be generated until the situation is resolved. That sounds like the kiss of death for any critical service. Can't it figure out ahead of time that this is going to happen and let the service keep running unchanged with a warning message about needing the update instead? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Message-ID: va.36bd.05799...@news.conactive.com On: Thu, 12 Feb 2009 10:31:23 +0100, Kai Schaetzl mailli...@conactive.com wrote: Ian Forde wrote on Wed, 11 Feb 2009 20:01:21 -0800: locate rpmsave locate rpmnew rpmsave is left from *un*installations, rpmnew is the *new* file, there is no file overwritten. rpm usually doesn't overwrite files if they got changed. And I haven't seen any overwrites with all the bind updates in the past months. So, I cannot back James' claim. Kai I cannot answer whether this situation is still the case, and I know that it was not always the case, but on the last but one update to bind my configuration files were all renamed to .rpmsave and there were no .rpmnew files created, only the default config files left in place of the old ones. I also believe, be cannot be sure, that this particular revision was a minor (9.X.y) as opposed to tiny (9.x.Y) update. I also believe that the same thing happened on the last update as well but, as I now do bind updates far more circumspectly, I may simply be confusing the present remedy with the original problem. In any case, the problem was not expected and it caused considerable grief until the problem was identified and the cause determined. It is just something that anyone hosting their own DNS should consider. The consequences of a dysfunction name server can be quite severe and can initially evidence itself in places that one would not immediately associate with DNS issues. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Thu, Feb 12, 2009, Les Mikesell wrote: Bill Campbell wrote: locate rpmsave locate rpmnew rpmsave is left from *un*installations, rpmnew is the *new* file, there is no file overwritten. rpm usually doesn't overwrite files if they got changed. AFAIK this is not correct, a package upgrade can create either of these (or both, or neither of them despite your having edited a file). And that's the way it should be, either choice can be justified. It depends on the package's SPEC file. rpm just does what it's told, everything is in the hands of the package maintainer. I think that the only time a .rpmnew file is created is if the SPEC file specifies ``%config(noreplace)'' for a file. If the ``noreplace'' option is not used, the .rpmsave files are created either when a package is removed, or when a file specified as a configuration file in the RPM SPEC file is updated and the file is sufficiently different from the default (for some definition of suffieiently). In the OpenPKG portable packaging system, which is RPM based, the presence of any .rpmnew or .rpmsave configuration files will prevent a package from starting, and warning messages will be generated until the situation is resolved. That sounds like the kiss of death for any critical service. Can't it figure out ahead of time that this is going to happen and let the service keep running unchanged with a warning message about needing the update instead? This has not proven a problem as we monitor updates, and generally know which packages may generate the rpmsave or rpmnew files as a result of testing on development machines before deploying to production systems. We have an administrative script that monitors the status of all servers running under our OpenPKG system, and quickly indicates anything that is not running while doing updates. In addition, our systems all check critical services under cron control, attempt to restart services that are not running, and notifying our support system via direct SMTP (bypassing postfix, amavisd, and clamv in case one of them is down) and with xmlrpc calls to our support servers as well. Our systems keep track of systems that are supposed to check in, and generate alerts when one or more miss checkins. Nothing is perfect of course, but this has worked well for us for almost 10 years now. Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 Most people, sometime in their lives, stumble across truth. Most jump up, brush themselves off, and hurry on about their business as if nothing had happened. - Sir Winston Churchill ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Thu, 2009-02-12 at 11:08 -0600, Les Mikesell wrote: That sounds like the kiss of death for any critical service. Can't it figure out ahead of time that this is going to happen and let the service keep running unchanged with a warning message about needing the update instead? You're missing the point. If the service is already running, the changes won't take effect until you restart the service with the new binaries. And the whole patching exercise is what maintenance windows are for, anyway. Note that it's critical SERVICE, not critical SERVER. The former is more important than the latter, so ideally you should be able to take down the latter in order to upgrade one implementation of the former. -I ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Thu, Feb 12, 2009, Ian Forde wrote: On Thu, 2009-02-12 at 11:08 -0600, Les Mikesell wrote: That sounds like the kiss of death for any critical service. Can't it figure out ahead of time that this is going to happen and let the service keep running unchanged with a warning message about needing the update instead? You're missing the point. If the service is already running, the changes won't take effect until you restart the service with the new binaries. And the whole patching exercise is what maintenance windows are for, anyway. Note that it's critical SERVICE, not critical SERVER. The former is more important than the latter, so ideally you should be able to take down the latter in order to upgrade one implementation of the former. I understand the distinction very well. In the time we have been using this method, we have never taken down a service for any significant period of time (the services are restarted on installation by the RPM SPEC files' %pre, %post processing). Of course we don't do things that are likely to take a critical service down without proper prior planning (often found out the hard way on our own systems :-). If an update is likely to have an impact on operations, it is scheduled during a maintenance window. The services that are most frequently updated are clamav, spamassassin, and amavisd-new, and we have often done this on heavily loaded MX servers (millions of e-mails a day) without having a service down for more than a minute or two while dealing with configuration file changes. Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 The Constitution is a written instrument. As such, its meaning does not alter. That which it meant when it was adopted, it means now. -- SOUTH CAROLINA v. US, 199 U.S. 437, 448 (1905) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Bill Campbell wrote: That sounds like the kiss of death for any critical service. Can't it figure out ahead of time that this is going to happen and let the service keep running unchanged with a warning message about needing the update instead? You're missing the point. If the service is already running, the changes won't take effect until you restart the service with the new binaries. And the whole patching exercise is what maintenance windows are for, anyway. Note that it's critical SERVICE, not critical SERVER. The former is more important than the latter, so ideally you should be able to take down the latter in order to upgrade one implementation of the former. I understand the distinction very well. In the time we have been using this method, we have never taken down a service for any significant period of time (the services are restarted on installation by the RPM SPEC files' %pre, %post processing). Of course we don't do things that are likely to take a critical service down without proper prior planning (often found out the hard way on our own systems :-). If an update is likely to have an impact on operations, it is scheduled during a maintenance window. In other words you'd dedicated sufficient human resources to undo whatever damage the package management system causes... -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Thu, Feb 12, 2009, Les Mikesell wrote: Bill Campbell wrote: That sounds like the kiss of death for any critical service. Can't it figure out ahead of time that this is going to happen and let the service keep running unchanged with a warning message about needing the update instead? You're missing the point. If the service is already running, the changes won't take effect until you restart the service with the new binaries. And the whole patching exercise is what maintenance windows are for, anyway. Note that it's critical SERVICE, not critical SERVER. The former is more important than the latter, so ideally you should be able to take down the latter in order to upgrade one implementation of the former. I understand the distinction very well. In the time we have been using this method, we have never taken down a service for any significant period of time (the services are restarted on installation by the RPM SPEC files' %pre, %post processing). Of course we don't do things that are likely to take a critical service down without proper prior planning (often found out the hard way on our own systems :-). If an update is likely to have an impact on operations, it is scheduled during a maintenance window. In other words you'd dedicated sufficient human resources to undo whatever damage the package management system causes... Isn't that what our customers are paying us to do? That has to be true now matter how one is doing updates. I have personally updated clamav on more than 50 machines in an afternoon without having any of them down for more than a minute, and that time mostly because clamav takes a while to restart. FWIW, we normally have clamav updates installed at all our client sites with 24 hours of the first notice that there's a new version out from swatch looking at the freshclamav.log file. This includes downloading the new tarball, updating the OpenPKG SRPM, building, testing in-house, and deployment. Often this is complete before people on this CentOS list start asking questions about the update or saying it won't build. Oh, and these updates are on a variety of Linux systems ranging from SuSE 9.0 Pro, SLES9, SLES10, CentOS 4.5 through CentOS 5.x, and at least one FreeBSD box -- all from the same SRPM file. Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 It will be of little avail to the people that the laws are made by men of their own choice if the laws be so voluminous that they cannot be read, or so incoherent that they cannot be understood. -James Madison, Federalist Paper #62 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Bill Campbell wrote: Of course we don't do things that are likely to take a critical service down without proper prior planning (often found out the hard way on our own systems :-). If an update is likely to have an impact on operations, it is scheduled during a maintenance window. In other words you'd dedicated sufficient human resources to undo whatever damage the package management system causes... Isn't that what our customers are paying us to do? That has to be true now matter how one is doing updates. Yes, but the extent to which it is actually required depends on how badly the intended automation fails. I think at least in theory, the parts of config files that are likely to need user modifications are supposed to be extracted to /etc/sysconfig/... so the files included in RPM updates generally won't have local changes and can be replaced without regard to the old contents. And programs suitable for inclusion in an 'enterprise' distribution should be designed so as not to require non-backwards-compatible changes in updates. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Nicolas Thierry-Mieg wrote on Thu, 12 Feb 2009 16:16:14 +0100: AFAIK this is not correct, a package upgrade can create either of these (or both, or neither of them despite your having edited a file). And that's the way it should be, either choice can be justified. Sure, a apckage can do anything, but that's how it usually is done. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Kai Schaetzl wrote: James B. Byrne wrote on Thu, 12 Feb 2009 12:31:39 -0500 (EST): I cannot answer whether this situation is still the case, and I know that it was not always the case, but on the last but one update to bind my configuration files were all renamed to .rpmsave and there were no .rpmnew files created, only the default config files left in place of the old ones. Hm, when I installed bind last year for providing caching and some internal name resolution in the LAN, it didn't install many config files. I had to make up the main files by my own. What I did to get this setup was to install bind, bind-chroot and caching-nameserver (and remove it later as I saw I didn't need it). After that I saw at least two updates, but no changes to config files. You should only install the caching-nameserver package if you have no local DNS config. The point of using it is that it supplies configs for caching-only operation. Any bind install will do caching, but the others expect you to do your own configuration with local zones. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Thu, Feb 12, 2009, Les Mikesell wrote: Bill Campbell wrote: Of course we don't do things that are likely to take a critical service down without proper prior planning (often found out the hard way on our own systems :-). If an update is likely to have an impact on operations, it is scheduled during a maintenance window. In other words you'd dedicated sufficient human resources to undo whatever damage the package management system causes... Isn't that what our customers are paying us to do? That has to be true now matter how one is doing updates. Yes, but the extent to which it is actually required depends on how badly the intended automation fails. I think at least in theory, the parts of config files that are likely to need user modifications are supposed to be extracted to /etc/sysconfig/... so the files included in RPM updates generally won't have local changes and can be replaced without regard to the old contents. And programs suitable for inclusion in an 'enterprise' distribution should be designed so as not to require non-backwards-compatible changes in updates. With OpenPKG all configuration files are under $prefix/etc/packagename where $prefix is the base directory of an OpenPKG instance (there may be more than one on a single system), and packagename is the name of the package, postfix, amavisd, clamav, mysql, etc. One of the basic principles of OpenPKG is to have absolutely minimal footprint on the installed system, only 7 lines in /etc/crontab, and the appropriate /etc/init.d entries (these actually vary depending on the type of host system). Some packages have multiple configuration files with only those for site parameters being declared at %config files in the RPM SPEC file. The issues occur when one has large, ugly configuration files (can we spell amavisd.conf :-), and there's a major version update with lots of new variables or variable name changes. FWIW, to bring this back to the djbdns topic, the *ONLY* configuration file in our OpenPKG packaging of djbdns, daemontools, and ucspi-tcp is the dnsroots.global file used by dnscache. Each server installed is in its own directory which is not affected by updates. Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 The only freedom which deserves the name, is that of pursuing our own good in our own way, so long as we do not attempt to deprive others of theirs, or impede their efforts to obtain it. -- John Stuart Mill, 1859 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
FWIW, to bring this back to the djbdns topic, the *ONLY* configuration file in our OpenPKG packaging of djbdns, daemontools, and ucspi-tcp is the dnsroots.global file used by dnscache. Each server installed is in its own directory which is not affected by updates. uscpi-tcp? Where does that come in? rsyncing of the cdb file? But yeah, thanks for pointing out that djbdns is zero maintenance save for its zone data which can be automated and therefore be to a large degree zero maintenance too. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Fri, Feb 13, 2009, Christopher Chan wrote: FWIW, to bring this back to the djbdns topic, the *ONLY* configuration file in our OpenPKG packaging of djbdns, daemontools, and ucspi-tcp is the dnsroots.global file used by dnscache. Each server installed is in its own directory which is not affected by updates. uscpi-tcp? Where does that come in? rsyncing of the cdb file? It's mostly to allow BIND sites to do zone transfers from djbdns sites. But yeah, thanks for pointing out that djbdns is zero maintenance save for its zone data which can be automated and therefore be to a large degree zero maintenance too. Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 There is far more danger in public than in private monopoly, for when Government goes into business it can always shift its losses to the taxpayers. Government never makes ends meet -- and that is the first requisite of business. -- Thomas Edison ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
uscpi-tcp? Where does that come in? rsyncing of the cdb file? It's mostly to allow BIND sites to do zone transfers from djbdns sites. Oh the axfr-dns daemon. This is the answer for the 'djbdns does not support tcp or zone transfer' nonsense routinely vomited by DJB haters. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Message-ID: 4991e3b7.6090...@andrei.myip.org On: Tue, 10 Feb 2009 12:29:43 -0800, Florin Andrei flo...@andrei.myip.org wrote: Jake wrote: We're about to start moving our public DNS to in-house managed servers. My first thought was Linux + BIND and we're done. Someone in another business unit's IT dept. has suggested tinydns be used. But things have changed. Nowadays Bind is solid enough. If you're still worried about security issues (you shouldn't, but I'm assuming the paranoid scenario) then CentOS has a good SELinux policy around it, so just install the latest CentOS, keep SELinux enabled, do a yum update every once in a while, and be at peace. By the way, this is also the most sweat-free solution from a sysadmining perspective. With one very large caveat. Be aware that updating bind via yum can result in your existing bind configuration files being renamed to something.rmpsave and your name server left in a dysfunctional state. I suggest that you consider excluding bind from normal updates and only update it when you are ready and able to check for possible configuration issues. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
James B. Byrne wrote: Be aware that updating bind via yum can result in your existing bind configuration files being renamed to something.rmpsave and your name server left in a dysfunctional state. I suggest that you consider excluding bind from normal updates and only update it when you are ready and able to check for possible configuration issues. Or put those files under Cfengine or Puppet and have auto-yum work with the config management system. But yeah, I agree, if the number of systems is small (so config management is not justified), avoid doing auto-updates to the critical components. -- Florin Andrei http://florin.myip.org/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Wed, 2009-02-11 at 17:34 -0500, James B. Byrne wrote: With one very large caveat. Be aware that updating bind via yum can result in your existing bind configuration files being renamed to something.rmpsave and your name server left in a dysfunctional state. I suggest that you consider excluding bind from normal updates and only update it when you are ready and able to check for possible configuration issues. That's true of pretty much every rpm that has config files... it's part of my standard updating routine: yum update updatedb locate rpmsave locate rpmnew fix any config files... restart services and/or reboot if necessary... -I ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Jake wrote: We're about to start moving our public DNS to in-house managed servers. My first thought was Linux + BIND and we're done. Someone in another business unit's IT dept. has suggested tinydns be used. Here's the straight dope: There was a time (circa 2000) when tinydns had a reason to exist. Back then, years ago, Bind was so horribly buggy, you couldn't afford to put it online, unless you were willing to deal with all the trouble. So many people, myself included, used tinydns extensively. It was tiny, fast, easy and solid. Also weird and unlike anything else (except DJB's own software). But we were an ISP and we just couldn't afford to babysit Bind all day long - DNS just had to continue working flawlessly. But things have changed. Nowadays Bind is solid enough. If you're still worried about security issues (you shouldn't, but I'm assuming the paranoid scenario) then CentOS has a good SELinux policy around it, so just install the latest CentOS, keep SELinux enabled, do a yum update every once in a while, and be at peace. By the way, this is also the most sweat-free solution from a sysadmining perspective. If you're serving a fairly large number of domains, or for some reason a SQL backend seems useful in your case, the alternative you're looking for is PowerDNS, not tinydns. The way tinydns became obsolete is nothing new. I remember using qmail back in the day - yes, I was a DJB fanboy. It was great, especially at a time when Sendmail had more holes in it than a metric ton of Swiss cheese. But then Postfix came along, and I had no reason to stick with qmail anymore. Such is the computer industry - licentious and forgetful. :-) -- Florin Andrei http://florin.myip.org/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Jake schrieb: Good morning: We're about to start moving our public DNS to in-house managed servers. My first thought was Linux + BIND and we're done. Someone in another business unit's IT dept. has suggested tinydns be used. From what I could find, it looks like this software hasn't really had any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this software? It seems to have some strong virtues but maybe not enough to justify using it over BIND just because any Linux admin we hire could be expected to know BIND. Thanks for your time, djbdns is OK - if you have some frontend that prepares the data-files for it. Otherwise, don't bother. Well, the same is true in some way for BIND - if you have more than a dozen or so zones with frequent updates, you'll swear, too. Just different swear-words ;-) How many zones do you manage, BTW? Also, if you need IPV6 etc - djbdns is not really predestined for this Rainer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Mon, 9 Feb 2009 10:22:42 -0500 Jake jakepau...@gmail.com wrote: From what I could find, it looks like this software hasn't really had any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this 1. DJBDNS does not need to be maintained: IT'S PERFECT. Bugless, no security hole... and does NOT support IPv6. 2. It's great, works like a rock. 3. Everything you need to know, including winning the loto, is at: http://www.lifewithdjbdns.com/ with all the explanations and the installation is toward the end of the page. -- Thanks http://www.911networks.com When the network has to work ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Mon, Feb 09, 2009 at 07:58:38AM -0800, cen...@911networks.com wrote: On Mon, 9 Feb 2009 10:22:42 -0500 Jake jakepau...@gmail.com wrote: From what I could find, it looks like this software hasn't really had any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this 1. DJBDNS does not need to be maintained: IT'S PERFECT. Bugless, no security hole... and does NOT support IPv6. 2. It's great, works like a rock. 3. Everything you need to know, including winning the loto, is at: http://www.lifewithdjbdns.com/ with all the explanations and the installation is toward the end of the page. Wasn't it released to public domain along with qmail? Surprised someone hasn't packaged this up for Fedora/EPEL yet if so. Maybe there was some hesitancy based on questions around its public domain status? I'm more familiar with BIND, but used djbdns at a previous job and it worked very well. Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Ray Van Dolson schrieb: On Mon, Feb 09, 2009 at 07:58:38AM -0800, cen...@911networks.com wrote: The problem is that it is not very modular. You must decided on which features (=patches) you want to incorporate and then build the RPM accordingly. We use tinydns+dnscache almost exclusively (it's not good if you need to play 2ndary for a true BIND) and are very happy with it. Rainer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
cen...@911networks.com wrote: From what I could find, it looks like this software hasn't really had any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this 1. DJBDNS does not need to be maintained: IT'S PERFECT. Bugless, no security hole... and does NOT support IPv6. 2. It's great, works like a rock. I've heard that story before about other djb code (qmail). Turned out to be horribly wrong and never fixed, so I'll never trust anything with those initials attached again. 3. Everything you need to know, including winning the loto, is at: http://www.lifewithdjbdns.com/ with all the explanations and the installation is toward the end of the page. I'd advice planning out a strategy to migrate your zones back to bind if you do go this route. Tinydns does some implicit magic that, if you use, will make someone's life difficult later when they try to figure out how to rebuild bind zone files to do the same thing. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Mon, Feb 09, 2009, Rainer Duffner wrote: Ray Van Dolson schrieb: On Mon, Feb 09, 2009 at 07:58:38AM -0800, cen...@911networks.com wrote: The problem is that it is not very modular. You must decided on which features (=patches) you want to incorporate and then build the RPM accordingly. We use tinydns+dnscache almost exclusively (it's not good if you need to play 2ndary for a true BIND) and are very happy with it. We have been using djbdns for years with excellent results, and user very few non-standard patches (mainly a hack to dnscache to allow it to respond to the world on one of our servers that we allowed customers to use in the mid '90s, and can't change). We are secondaries for a few hundred BIND domains, and have no problems with that using djb tcpclient axfr-get to pull the data from these under control of a cron job. We are also provide secondary DNS for many of our customer's sites which run djbdns, and they simply use rsync to copy their zone files to our primary server. We use the rbldns daemon extensively to handle DNSRBLs. The data formats for djbdns are quite simple, particularly compared to the ugly kludge of BIND. Setting up forward and reverse DNS for a host for which one is authoritative for the in-addr address requires a single line, at a minimum: =fqdn:ipaddress: The startup times are essentially zero, as are updates to remote servers using rsync to copy the tinydns and rbldns data files to our secondary servers. The version we run on all our Linux systems has been hacked into SRPMS for the OpenPKG portable package management system, and we run it on various Linux distributions, FreeBSD, and OS X. I don't remember exactly when we started using djbdns, but it was at least 8 years ago. Other than a simple hack I did years ago to have dnscache ignore CVS and RCS directories, it has been dead solid with zero problems. Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 Those who cast the vote decide nothing. Those who count the vote decide everything. (Joseph Stalin) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Thank you very much for all of your feedback. It really sounds like i got two general replies: eh, I wouldn't use it (a minority) and We do some complicated stuff to make it meet our needs and we love it. (majority) For us, ease of management is really key to having success with our technical staff. I think we'll likely stick with BIND. -Jake On Mon, Feb 9, 2009 at 1:02 PM, Bill Campbell cen...@celestial.com wrote: On Mon, Feb 09, 2009, Rainer Duffner wrote: Ray Van Dolson schrieb: On Mon, Feb 09, 2009 at 07:58:38AM -0800, cen...@911networks.com wrote: The problem is that it is not very modular. You must decided on which features (=patches) you want to incorporate and then build the RPM accordingly. We use tinydns+dnscache almost exclusively (it's not good if you need to play 2ndary for a true BIND) and are very happy with it. We have been using djbdns for years with excellent results, and user very few non-standard patches (mainly a hack to dnscache to allow it to respond to the world on one of our servers that we allowed customers to use in the mid '90s, and can't change). We are secondaries for a few hundred BIND domains, and have no problems with that using djb tcpclient axfr-get to pull the data from these under control of a cron job. We are also provide secondary DNS for many of our customer's sites which run djbdns, and they simply use rsync to copy their zone files to our primary server. We use the rbldns daemon extensively to handle DNSRBLs. The data formats for djbdns are quite simple, particularly compared to the ugly kludge of BIND. Setting up forward and reverse DNS for a host for which one is authoritative for the in-addr address requires a single line, at a minimum: =fqdn:ipaddress: The startup times are essentially zero, as are updates to remote servers using rsync to copy the tinydns and rbldns data files to our secondary servers. The version we run on all our Linux systems has been hacked into SRPMS for the OpenPKG portable package management system, and we run it on various Linux distributions, FreeBSD, and OS X. I don't remember exactly when we started using djbdns, but it was at least 8 years ago. Other than a simple hack I did years ago to have dnscache ignore CVS and RCS directories, it has been dead solid with zero problems. Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 Those who cast the vote decide nothing. Those who count the vote decide everything. (Joseph Stalin) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Jake Paulus jakepau...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Mon, Feb 09, 2009 at 03:07:30PM -0500, Jake wrote: Thank you very much for all of your feedback. It really sounds like i got two general replies: eh, I wouldn't use it (a minority) and We do some complicated stuff to make it meet our needs and we love it. (majority) For us, ease of management is really key to having success with our technical staff. I think we'll likely stick with BIND. -Jake Yep. Honestly, both work well. Use whatever you have more expertise or experience in. Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
Jake wrote: Good morning: We're about to start moving our public DNS to in-house managed servers. My first thought was Linux + BIND and we're done. Someone in another business unit's IT dept. has suggested tinydns be used. From what I could find, it looks like this software hasn't really had any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this software? It seems to have some strong virtues but maybe not enough to justify using it over BIND just because any Linux admin we hire could be expected to know BIND. tinydns supports large zone/record updates on the fly...in comparison with bind which will stop answering while it is loading up zones. The caveat however is that you need GOOD disk i/o if you have a lot of records because tinydns achieves that due to use a cdb database whereas BIND will stick them all in memory. So if you are constantly updating zones, I would suggest tinydns as the entire process can be automated and the source for the cdb database stored in a nice sql database with a nice frontend, script plugin/api for whatever you imagine. If you don't have very dynamic stuff and you do not need to constantly rebuild zones, BIND should be better I suppose especially if you are in an environment where a lot of zones share the same data (ns, mx,...) thanks to INCLUDE. As for making sure the system stays up-to-date, you do not have to worry about djbdns and daemontools...they are pretty much set in stone now excpet for maybe some patches that you might want (it's public domain so just roll your own if you do need them patches). All you have to worry about is installing on new systems. It is literally compile once and forget. Zero overhead. Oh, may I point out that there are no security issues with djbdns whereas BIND has a history of problems even until recently. 'slaves' can be updated with by rsyncing the cdb database over so there is no room for human error with respects to dns server configuration whether it is leaving recursive on or whatever. Interesting that any Linux admin you can hire will know BIND. I find that not to be the case over here in Hong Kong. I guess there is a reason why Linux is not very popular over here notwithstanding the lack of people who know Linux. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tinydns/djbdns opinion poll
On Mon, 2009-02-09 at 15:07 -0500, Jake wrote: Thank you very much for all of your feedback. It really sounds like i got two general replies: eh, I wouldn't use it (a minority) and We do some complicated stuff to make it meet our needs and we love it. (majority) For us, ease of management is really key to having success with our technical staff. I think we'll likely stick with BIND. -Jake Jake, We are a small company and started using BIND 3 years ago so that we could control local access within the network with local zones for 3 remote sites. Everything on the network works better with your own DNS service. Most of my sendmail problems were immediately solved as well as others. A local DNS is great and BIND was easy for us to use. Good Luck!! Greg ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
