>> 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.
___
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 i
> 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 do
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,
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
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 a
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 cr
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 windo
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
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
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 ab
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
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
Message-ID:
On: Thu, 12 Feb 2009 10:31:23 +0100, 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 fi
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
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 o
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 c
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 updat
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
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
Message-ID: <4991e3b7.6090...@andrei.myip.org>
On: Tue, 10 Feb 2009 12:29:43 -0800, Florin Andrei
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
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 re
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
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 re
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, e
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
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 acc
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
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
On Mon, Feb 09, 2009 at 07:58:38AM -0800, cen...@911networks.com wrote:
> On Mon, 9 Feb 2009 10:22:42 -0500
> Jake 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
On Mon, 9 Feb 2009 10:22:42 -0500
Jake 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 th
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
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
33 matches
Mail list logo
