Re: Dovecot and Resolvconf issues
On Mon, Mar 31, 2008 at 04:01:56PM +0300, chavdar wrote:
> Dear list,
> 2. Resolvconf
> So far, we manipulated our network settings for the server
> through /etc/resolv.conf - where we supply a list of DNS servers to be
> The new system has that file, manipulated by the program resolvconf, and
> any changes we put there are being wiped out periodically. man
> resolvconf has no solution and we are stuck, because we rely on another
> host for DNS.
You do not write directly to /etc/resolv.conf if you are using
resolvconf. Just remove it and manually configure /etc/resolv.conf.
> You may have noticed that I seldom post here and never complained, but
> these changes are too dramatic and not documented (after reading all
> info at dovecot website and wiki, we are certain that our config is
Usage information for administrators
The generation of the resolv.conf file can be controlled by editing
/etc/resolvconf/update.d/libc . Different strategies can be
followed. E.g., one possible strategy would be to put only the most
recently provided information into resolv.conf . The current default
strategy is to put *all* available resolver information into
resolv.conf, ordered by interface type as follows: lo, eth*, ppp* .
The admin can of course disable resolv.conf automagic by deleting the
/etc/resolv.conf symlink and putting a static file at that location.
Once you have installed resolvconf properly you don't normally need
to run /sbin/resolvconf from the command line. However, I once
encountered a situation in which I did that. Perhaps it is a useful
illustration. My ISP's nameserver went down and thus my caching
nameserver could not resolve names. I knew of another host belonging
to by ISP that I could use so I simply did:
# echo "nameserver ww.xx.yy.zz" | resolvconf -a dummy
This added the necessary nameserver line to /etc/resolv.conf and to
dnsmasq's nameserver list. When my ISP's regular nameserver was fixed
# resolvconf -d dummy
> Please, if you have solution to these issues, share them with us because
> otherwise our mailserver is working perfectly well and we would like to
> keep it.
I hope this new tutorial also makes it easy to find your answer.