9:27 p.m.
I see on last rawhide update that NetworkManager now requires bind and
caching-nameserver. But the named service (bind) was not turned on:
$ /sbin/chkconfig --list named
named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Is it supposed to be turned on for NetworkManager?
11:25 p.m.
New subject: NetworkManager ( & bind)
On Wed, 12 Jan 2005, Sandy Pond wrote:
I see on last rawhide update that NetworkManager now requires bind
and
caching-nameserver. But the named service (bind) was not turned on:
$ /sbin/chkconfig --list named
named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Is it supposed to be turned on for NetworkManager?
I see this update for FC3 (not rawhide).
Any idea why NetworkManager requires bind?
Satish
9:18 a.m.
New subject: NetworkManager ( & bind)
On Wed, 2005-01-12 at 23:25 -0600, Satish Balay wrote:
On Wed, 12 Jan 2005, Sandy Pond wrote:
> I see on last rawhide update that NetworkManager now requires bind and
> caching-nameserver. But the named service (bind) was not turned on:
>
> $ /sbin/chkconfig --list named
> named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
>
> Is it supposed to be turned on for NetworkManager?
I see this update for FC3 (not rawhide).
Any idea why NetworkManager requires bind?
It uses bind in a caching-nameserver functionality and named should
_not_ be turned on my default in this configuration. Use of bind as a
caching nameserver was done to work around deficiencies of nscd and
glibc and should allow user applications to be aware of changes
to /etc/resolv.conf faster, since the applications actually just talk to
127.0.0.1 for the nameserver, and its the caching-nameserver that
actually does the heavy lifting when /etc/resolv.conf changes since
glibc isn't up to the task.
Dan
9:20 a.m.
New subject: NetworkManager ( & bind)
On Thu, 2005-01-13 at 10:18 -0500, Dan Williams wrote:
On Wed, 2005-01-12 at 23:25 -0600, Satish Balay wrote:
> On Wed, 12 Jan 2005, Sandy Pond wrote:
>
> > I see on last rawhide update that NetworkManager now requires bind and
> > caching-nameserver. But the named service (bind) was not turned on:
> >
> > $ /sbin/chkconfig --list named
> > named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
> >
> > Is it supposed to be turned on for NetworkManager?
>
> I see this update for FC3 (not rawhide).
>
> Any idea why NetworkManager requires bind?
It uses bind in a caching-nameserver functionality and named should
_not_ be turned on my default in this configuration. Use of bind as a
caching nameserver was done to work around deficiencies of nscd and
glibc and should allow user applications to be aware of changes
to /etc/resolv.conf faster, since the applications actually just talk to
127.0.0.1 for the nameserver, and its the caching-nameserver that
actually does the heavy lifting when /etc/resolv.conf changes since
glibc isn't up to the task.
Dan
So my FC3 machine tells me that there is an unresolvable chain of
dependencies and doesn't install the updates.
I have a standard workstation install.
--
Will Backman
Coastal Enterprises, Inc.
The ozone layer or cheese in a spray can. Don't make me choose.
9:34 a.m.
New subject: NetworkManager ( & bind)
On Thu, 2005-01-13 at 10:30 -0500, Dan Williams wrote:
On Thu, 2005-01-13 at 10:20 -0500, Will Backman wrote:
> So my FC3 machine tells me that there is an unresolvable chain of
> dependencies and doesn't install the updates.
What exactly is the error it spits out?
Dan
There was a package dependency problem. The message was:
Unresolvable chain of dependencies:
NetworkManager 0.3.3-1.cvs20050112.1.fc requires bind
NetworkManager 0.3.3-1.cvs20050112.1.fc requires caching-nameserver
Please modify your package selections and try again.
--
Will Backman
Coastal Enterprises, Inc.
The ozone layer or cheese in a spray can. Don't make me choose.
9:36 a.m.
New subject: NetworkManager ( & bind)
Will Backman wrote:
>>
>>Any idea why NetworkManager requires bind?
>
>It uses bind in a caching-nameserver functionality and named should
>_not_ be turned on my default in this configuration. Use of bind as a
>caching nameserver was done to work around deficiencies of nscd and
>glibc and should allow user applications to be aware of changes
>to /etc/resolv.conf faster, since the applications actually just talk to
>127.0.0.1 for the nameserver, and its the caching-nameserver that
>actually does the heavy lifting when /etc/resolv.conf changes since
>glibc isn't up to the task.
>
>Dan
>
So my FC3 machine tells me that there is an unresolvable chain of
dependencies and doesn't install the updates.
I have a standard workstation install.
Actually, my FC3 machine does install the updates, and installs bind
/and/ the caching-nameserver to resolve the dependencies.
Here is my up2date sources file:
---BEGIN FILE---
### This describes the various package repositories (repos) that up2date
will
### query for packages. It currently supports apt-rpm, yum, and "dir" repos.
### Format is one repository (repo) entry per line, # starts comments, the
### first word on each line is the type of repo.
### The default RHN (using "default" as the url means use the one in the
### up2date config file).
#up2date default
### Note: when a channel label is required for the non up2date repos,
### the label is solely used as an internal identifier and is not
### based on the url or any other info from the repos.
### An apt style repo (the example is arjan's 2.6 kernel repo).
### The format is:
### type channel-label service:server path repo name
#apt arjan-2.6-kernel-i386 http://people.redhat.com ~arjanv/2.5/ kernel
### Note: for apt repos, there can be multiple repo names specified (space
### seperated).
### A yum style repo. The format is:
### type channel-label url
### A local directory full of packages (a "dir" repo). For example:
#dir my-favorite-rpms /var/spool/RPMS/
# Multiple versions of all repos except "up2date" can be used. Dependencies
# can be resolved "cross-repo" if need be.
#
# base
# Fedora Core 3 - i386 - Base
#
apt base http://ayo.freshrpms.net fedora/linux/3/i386 core
#
# updates-released
# Fedora Core 3 - i386 - Released Updates
#
apt updates-released http://ayo.freshrpms.net fedora/linux/3/i386 updates
#
# updates-testing
# Fedora Core 3 - i386 - Unreleased Updates
#
# apt updates-testing http://ayo.freshrpms.net fedora/linux/3/i386 tupdates
#
# fedoralegacyupdates
# Fedora Core 3 - i386 - Released Updates by FedoraLegacy
#
# apt fedoralegacyupdates http://download.fedoralegacy.org/apt
fedora/3/i386 updates
#
# atrpms
# Fedora Core 3 - i386 - ATrpms
# alternatives to stable: testing and bleeding
#
apt atrpms http://apt.atrpms.net fedora/3/en/i386 at-stable
yum fedora-core-3
http://download.fedora.redhat.com/pub/fedora/linux/core/3/$ARCH/os/
yum updates-released-fc3
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/$ARCH/
yum-mirror fedora-core-3
http://fedora.redhat.com/download/up2date-mirrors/fedora-core-3
yum-mirror updates-released-fc3
http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc3
yum dag http://apt.sw.be/fedora/3/en/$ARCH/dag
---END OF FILE---
As you can see, I use freshrpms, at-stable, and dag, in addition to the
traditional fedora-core-3 and updates-released-fc3 repositories. (I
edited my up2date file to skip the "libhowl" packages from at-stable;
they force too many removals.)
Temlakos
9:31 a.m.
New subject: NetworkManager ( & bind)
Once upon a time, Dan Williams <dcbw(a)redhat.com> said:
On Wed, 2005-01-12 at 23:25 -0600, Satish Balay wrote:
> Any idea why NetworkManager requires bind?
It uses bind in a caching-nameserver functionality and named should
_not_ be turned on my default in this configuration.
This new requirement broke my local named config. I had bind installed
but not caching-nameserver; installing caching-nameserver (to fulfill
the dependency) moved my named.conf to named.conf.rpmsave and yum didn't
even tell me about it.
NetworkManager's RPM says "It is intended only for the desktop use-case,
and is not intended for usage on servers.", yet it is installed by
default in the "Base" group (which means going forward bind and
caching-nameserver will also be installed by default). I don't need
this if I'm building a firewall or server (it actually gets in the way
of configuring bind).
It seems that too many things are creeping into Base; what makes
"cyrus-sasl-plain" or "mt-st" or "slocate" mandatory? Why
are Bluetooth
utils and "numactl" included in Base by default?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:45 a.m.
New subject: NetworkManager ( & bind)
On Thu, 2005-01-13 at 09:31 -0600, Chris Adams wrote:
NetworkManager's RPM says "It is intended only for the
desktop use-case,
and is not intended for usage on servers.", yet it is installed by
default in the "Base" group (which means going forward bind and
caching-nameserver will also be installed by default). I don't need
this if I'm building a firewall or server (it actually gets in the way
of configuring bind).
I believe I was in error adding the caching-nameserver dep, I'll remove
that and push another update.
Dan
3:45 p.m.
New subject: NetworkManager ( & bind)
On Thu, 2005-01-13 at 10:45 -0500, Dan Williams wrote:
On Thu, 2005-01-13 at 09:31 -0600, Chris Adams wrote:
> NetworkManager's RPM says "It is intended only for the desktop use-case,
> and is not intended for usage on servers.", yet it is installed by
> default in the "Base" group (which means going forward bind and
> caching-nameserver will also be installed by default). I don't need
> this if I'm building a firewall or server (it actually gets in the way
> of configuring bind).
I believe I was in error adding the caching-nameserver dep, I'll remove
that and push another update.
I actually appear to be wrong on this one, we _do_ need caching-
nameserver from what Colin Walters says, since some of the configuration
for named is stored in the config files /other/ than the main one (ie
reverse DNS info he said?). It seems to be a packaging issue for
caching-nameserver more or less.
Dan
10:14 p.m.
New subject: NetworkManager ( & bind)
On Thu, 2005-01-13 at 16:45 -0500, Dan Williams wrote:
On Thu, 2005-01-13 at 10:45 -0500, Dan Williams wrote:
> On Thu, 2005-01-13 at 09:31 -0600, Chris Adams wrote:
> > NetworkManager's RPM says "It is intended only for the desktop
use-case,
> > and is not intended for usage on servers.", yet it is installed by
> > default in the "Base" group (which means going forward bind and
> > caching-nameserver will also be installed by default). I don't need
> > this if I'm building a firewall or server (it actually gets in the way
> > of configuring bind).
>
> I believe I was in error adding the caching-nameserver dep, I'll remove
> that and push another update.
I actually appear to be wrong on this one, we _do_ need caching-
nameserver from what Colin Walters says, since some of the configuration
for named is stored in the config files /other/ than the main one (ie
reverse DNS info he said?). It seems to be a packaging issue for
caching-nameserver more or less.
Dan
Will NetworkManager not be in the base install for anaconda "server"
installation?
8:24 a.m.
New subject: NetworkManager ( & bind)
On Thu, 2005-01-13 at 23:14 -0500, Sandy Pond wrote:
Will NetworkManager not be in the base install for anaconda
"server"
installation?
Yes, it should not be installed for servers. NetworkManager is really
only useful in a desktop context, and is mostly targetted at laptops
where the user is mobile. At this point, it doesn't really make sense
for server environments, though that capability may well creep in at
future points.
Dan
5:10 p.m.
New subject: NetworkManager ( & bind)
On Fri, 14 Jan 2005 09:24:53 -0500, Dan Williams <dcbw(a)redhat.com> wrote:
On Thu, 2005-01-13 at 23:14 -0500, Sandy Pond wrote:
> Will NetworkManager not be in the base install for anaconda "server"
> installation?
Yes, it should not be installed for servers. NetworkManager is really
only useful in a desktop context, and is mostly targetted at laptops
where the user is mobile. At this point, it doesn't really make sense
for server environments, though that capability may well creep in at
future points.
So if bind is turned off... then how is NetworkManager doing lookups?
And why cant nscd be 'fixed' to do these?
Sorry I just dont like having a bind server on boxes that arent DNS
servers.. you deal with one BIND exploit and it taints you :). It also
seems to be heading towards everyone needing 1 gig of ram and a 3 ghz
dekstop to even run effectively.
[Hope this isnt too cranky.. little sleep.]
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
3:48 p.m.
New subject: NetworkManager ( & bind)
On Fri, Jan 14, 2005 at 09:24:53AM -0500, Dan Williams wrote:
On Thu, 2005-01-13 at 23:14 -0500, Sandy Pond wrote:
> Will NetworkManager not be in the base install for anaconda "server"
> installation?
Yes, it should not be installed for servers. NetworkManager is really
only useful in a desktop context, and is mostly targetted at laptops
where the user is mobile. At this point, it doesn't really make sense
for server environments, though that capability may well creep in at
future points.
I'd really like to see dynamic network configuration make its way into the
server base. The existing static configuration via the network scripts in
the initscripts package fails to utilize even a small fraction of the Linux
networking stack functionality added by Alexey Kuznetsov and others starting
back in the 2.2 kernel. We are still using BSD-like initscripts, when the
Linux kernel has more in common with Cisco IOS.
Part of the problem is that integration is required to configure many
different subsystems: interfaces, tunnels, ipsec, policy routing rules,
routing tables, arptables, netfilter, traffic control, vrrp, etc. When the
network topology changes, *all* of these subsystems are potentially affected.
A combination of event-driven state changes and more "aspect-oriented"
configuration syntax would ease the burden of, e.g., setting up
firewall routers with multiple upstream providers with differing QoS, etc.
Current Linux best practice in this instance, AFAIK, is documented on
Julian Anastasov's web pages: http://www.ssi.bg/~ja/ ; his kernel patches
mostly help to work around the lack of dynamic configuration in userspace.
I suppose that is why they have not been merged after many years.
I'm sure that there's a Ph.D. or two up for grabs for getting the details
right.
Regards,
Bill Rugolsky
5:21 p.m.
New subject: NetworkManager ( & bind)
Dan Williams (dcbw(a)redhat.com) said:
It uses bind in a caching-nameserver functionality and named should
_not_ be turned on my default in this configuration. Use of bind as a
caching nameserver was done to work around deficiencies of nscd and
glibc and should allow user applications to be aware of changes
to /etc/resolv.conf faster, since the applications actually just talk to
127.0.0.1 for the nameserver, and its the caching-nameserver that
actually does the heavy lifting when /etc/resolv.conf changes since
glibc isn't up to the task.
Why can't this be solved with nscd and use of 'nscd -i hosts' when
resolv.conf changes, out of curiousity?
Bill
10:47 p.m.
New subject: The problem with nscd (was RE: NetworkManager & bind)
Bill & everyone,
Here's the problem. 'nscd -i hosts' isn't adequate for all cases.
Specifically (and you can argue about its relevance), nscd doesn't
interrupt in-process resolution calls and return current information
immediately. Instead, if /etc/resolv.conf gets changed from underneath
'nscd' and you call 'nscd -i hosts', an app like Mozilla will sit there
until it times out because nscd is too dumb to deal with changed
information in the middle of a gethostbyname().
For example:
1) Stick bogus information in /etc/resolv.conf
2) service nscd start
3) nscd -i hosts (to clear all previous cached hosts)
4) Fire up mozilla, "www.google.com"
(mozilla will sit there resolving as the DNS servers are incorrect)
5) correct /etc/resolv.conf with good DNS servers
6) nscd -i hosts
7) WAIT FOREVER (15 - 20 seconds)
Using a caching nameserver, and restarting the nameserver, works
correctly, every time, all the time. Try getting something (/Anything/)
past Uli, let alone something with the name resolver.
Note that killing nscd and restarting a fresh copy doesn't work either.
Server-types and those people who don't actually use a desktop may argue
that this delay is acceptable, but its not, even if it occurs 10% of the
time for 10% of the users.
Furthermore, I've run into cases where just 'nscd -i hosts' is inadequate,
as I did when I was testing to make sure I knew what I was talking about
here. I had an nscd running, copied over a bogus /etc/resolv.conf, and
did 'nscd -i hosts', but apps could still resolv names when clearly they
should not have due to the bogus resolv.conf and the invalidated hosts
cache. nscd simply doesn't work well enough, caching-nameservers do.
Were these problems in nscd/glibc corrected, we'd love to switch back to
nscd becacuse its simply less complicated, which is bonus. But not if it
doesn't work.
Dan
On Fri, 14 Jan 2005, Bill Nottingham wrote:
Dan Williams (dcbw(a)redhat.com) said:
> It uses bind in a caching-nameserver functionality and named should
> _not_ be turned on my default in this configuration. Use of bind as a
> caching nameserver was done to work around deficiencies of nscd and
> glibc and should allow user applications to be aware of changes
> to /etc/resolv.conf faster, since the applications actually just talk to
> 127.0.0.1 for the nameserver, and its the caching-nameserver that
> actually does the heavy lifting when /etc/resolv.conf changes since
> glibc isn't up to the task.
Why can't this be solved with nscd and use of 'nscd -i hosts' when
resolv.conf changes, out of curiousity?
Bill
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
http://www.redhat.com/mailman/listinfo/fedora-test-list
3:40 p.m.
New subject: The problem with nscd (was RE: NetworkManager & bind)
Dan Williams (dcbw(a)redhat.com) said:
Here's the problem. 'nscd -i hosts' isn't adequate
for all cases.
Specifically (and you can argue about its relevance), nscd doesn't
interrupt in-process resolution calls and return current information
immediately. Instead, if /etc/resolv.conf gets changed from underneath
'nscd' and you call 'nscd -i hosts', an app like Mozilla will sit there
until it times out because nscd is too dumb to deal with changed
information in the middle of a gethostbyname().
For example:
1) Stick bogus information in /etc/resolv.conf
2) service nscd start
3) nscd -i hosts (to clear all previous cached hosts)
4) Fire up mozilla, "www.google.com"
(mozilla will sit there resolving as the DNS servers are incorrect)
5) correct /etc/resolv.conf with good DNS servers
6) nscd -i hosts
7) WAIT FOREVER (15 - 20 seconds)
OK, I'd argue that this isn't a particularly relevant usage case.
How often do people really change their DNS servers *in the
middle of a lookup?*
Note that killing nscd and restarting a fresh copy doesn't work
either.
Server-types and those people who don't actually use a desktop may argue
that this delay is acceptable, but its not,
Nice strawman there.
even if it occurs 10% of the time for 10% of the users.
... which I highly doubt.
Furthermore, I've run into cases where just 'nscd -i
hosts' is inadequate,
as I did when I was testing to make sure I knew what I was talking about
here. I had an nscd running, copied over a bogus /etc/resolv.conf, and
did 'nscd -i hosts', but apps could still resolv names when clearly they
should not have due to the bogus resolv.conf and the invalidated hosts
cache. nscd simply doesn't work well enough, caching-nameservers do.
Then that's bugs in nscd that should be fixed, not a reason to install
*bind* on all desktops.
Bill
8:23 a.m.
New subject: The problem with nscd (was RE: NetworkManager & bind)
On Sun, 2005-01-16 at 23:47 -0500, Dan Williams wrote:
Here's the problem. 'nscd -i hosts' isn't adequate
for all cases.
Specifically (and you can argue about its relevance), nscd doesn't
interrupt in-process resolution calls and return current information
immediately. Instead, if /etc/resolv.conf gets changed from underneath
'nscd' and you call 'nscd -i hosts', an app like Mozilla will sit there
until it times out because nscd is too dumb to deal with changed
information in the middle of a gethostbyname().
The number and percentage of name resolution requests that fail because
the name servers were changed IN THE MIDDLE OF the query is,
statistically, zero. Or so close to it as to make the difference
irrelevant.
In whatever tiny, minuscule fraction of cases this would actually be a
problem, I'll note that this problem has always existed on Linux and on
Windows as well. Any time you change the nameservers, whatever queries
you had in process would time out waiting for the old nameservers, or
return a value (correct or incorrect) from the old nameservers. In-
process queries have never yet, in any OS in which I have personal
experience, magically caught a nameserver change in mid-query.
Furthermore, I submit that such an ability to change direction in midair
is not important. Desirable, yes. Important, not at all!
It is CERTAINLY not a reason to install BIND on all desktops. Bloat,
increased resource requirements, increased security risk, slower system
response, pick your reasons... all of these are applicable and true to
some degree.
Something is *VERY* wrong if you need to install BIND on a desktop just
to switch from home to office networks, and if you do this just to save
the case where a DNS query times out because the nameserver info was
changed.
This is *not* a good move, guys... no no no no no. Dan, you have done
amazing work with NetworkManager and it's moving forward very well; but
this idea is a mistake! Pure and simple.
Note that killing nscd and restarting a fresh copy doesn't work
either.
Server-types and those people who don't actually use a desktop may argue
that this delay is acceptable, but its not, even if it occurs 10% of the
time for 10% of the users.
I use a Linux notebook as my primary work machine, and I move between
four or five different networks every day. I think I have approximately
one DNS query time out due to changed nameserver or network information
about once or twice a month. And for this, you want to require BIND???
10% of the time for 10% of the users is *ridiculously* high. If, in a
month, I work only 8 hours a day (ha!) for 22 days, that's 10,560
minutes. And if this happened ONCE A DAY and I lost a WHOLE MINUTE, then
I'd be losing 22 minutes a month or 0.2% of the time.
And I doubt like hell that 10% of the users move around as much as I do.
There must, repeat must, be a better simpler easier way. Or you might
need to accept the status quo that historically in-process queries
*aren't* smart enough to see a change in nameservers, and that this
single query will time out.
Were these problems in nscd/glibc corrected, we'd love to switch
back to
nscd becacuse its simply less complicated, which is bonus. But not if it
doesn't work.
This cure is worse than the disease. Substantially so.
Cheers, and keep up the good work!
--
Rodolfo J. Paiz <rpaiz(a)simpaticus.com>
8:34 a.m.
New subject: The problem with nscd (was RE: NetworkManager & bind)
On Tue, Jan 18, 2005 at 08:23:23AM -0600, Rodolfo J. Paiz wrote:
It is CERTAINLY not a reason to install BIND on all desktops. Bloat,
increased resource requirements, increased security risk, slower system
response, pick your reasons... all of these are applicable and true to
some degree.
Definitely true. In addition bind won't work at all through a strong firewall
or worse yet can be used for systematic DoS attacks aimed at taking out
NAT tracking firewalls running UDP sessions. These attacks are very well
known and understood. [1]
Installing bind is not a solution.
Alan
[1] It goes like this
Your NAT box has finite resources for UDP sessions
If you visit a web page I control then I can serve a page that includes
an iframe reloading continually each time with a new DNS query
required all of which point to a host I control.
After about 60,000 dns queries (maybe only a couple of minute) you are out
of UDP ports. Worse yet in many cases you will be querying my DNS server
from your DNS server and making temporary holes in the firewall between the
two. I can now see through your firewall in limited ways with probable port
reuse going to land me access to something.
5:04 p.m.
On Wed, 12 Jan 2005 22:27:27 -0500, Sandy Pond <sandy_pond(a)myrealbox.com> wrote:
I see on last rawhide update that NetworkManager now requires bind
and
caching-nameserver. But the named service (bind) was not turned on:
$ /sbin/chkconfig --list named
named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Is it supposed to be turned on for NetworkManager?
Personally I think that something is wrong in RPM dependencies if
caching name-server and bind are needed.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
7045
days inactive
7050
days old
20 comments
11 participants
participants (11)
-
Alan Cox -
Bill Nottingham -
Bill Rugolsky Jr. -
Chris Adams -
Dan Williams -
Rodolfo J. Paiz -
Sandy Pond -
Satish Balay -
Stephen John Smoogen -
Temlakos -
Will H. Backman