Apt-get update do not work

OS type and version Debian 10
Webmin version 1.981
Usermin version 1.823
Virtualmin version 6.17-3

I cannot upgrade Debian either through Webmin or apt-get update. What can I do to solve this?

> apt-get update
Err:1 http://software.virtualmin.com/vm/6/gpl/apt virtualmin-buster InRelease
  Temporary failure resolving 'software.virtualmin.com'
Err:2 http://security.debian.org/debian-security buster/updates InRelease
  Temporary failure resolving 'security.debian.org'
Err:3 http://deb.debian.org/debian buster InRelease
  Temporary failure resolving 'deb.debian.org'
Err:4 http://software.virtualmin.com/vm/6/gpl/apt virtualmin-universal InRelease
  Temporary failure resolving 'software.virtualmin.com'
Err:5 http://deb.debian.org/debian buster-updates InRelease
  Temporary failure resolving 'deb.debian.org'
Reading package lists...
W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease  Temporary failure resolving 'deb.debian.org'
W: Failed to fetch http://security.debian.org/debian-security/dists/buster/updates/InRelease  Temporary failure resolving 'security.debian.org'
W: Failed to fetch http://deb.debian.org/debian/dists/buster-updates/InRelease  Temporary failure resolving 'deb.debian.org'
W: Failed to fetch http://software.virtualmin.com/vm/6/gpl/apt/dists/virtualmin-buster/InRelease  Temporary failure resolving 'software.virtualmin.com'
W: Failed to fetch http://software.virtualmin.com/vm/6/gpl/apt/dists/virtualmin-universal/InRelease  Temporary failure resolving 'software.virtualmin.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.

You don’t have working domain resolution, which has nothing to do with Virtualmin.
Check your /etc/resolv.conf.



Is there any problem with this? Have Webmin DNS activated?

My VPS vendor gave me this answer:

it sounds like some networking settings (DNS is clearly affected) have been changed as part of the Virtualmin installation.

The apt-get update worked before I installed Virtualmin so any clue how to solve this is appreciated.

I have found the cause of the problem. It is neither Virtualmin nor the VPS. The firewall rules are the problem. I shut off the firewall and it worked.

I need to know which port should be open in order to be able to run apt-get update?

in resolv you can have this and protect that file with chatrr…

While after reboot… :slight_smile:

Generated by NetworkManager

search (hereyourmaindomainfor server so no hostname but domain) (this without () )

or something like that depending where which os / hoster and yes no networkmanager and network things you need , nameserver ip hoster in theit network sometimes needed to

No it is not that update but the dns resolving names normally port 53 or 953 depending your configs.
If not open thos portnrs in firewall then why?

Default they are almost in every firewall set.

1 Like

I am not sure that it was the firewall. As resolv.conf was overwritten automatically. So far this seems to work.

  1. Install resolvconf (a tool?)
  2. Add my nameservers in /etc/resolvconf/resolv.conf.d/tail
  3. Reboot and the resolv.conf was persistant.

Thank you for pointing me in the right direction!

But as resolv.conf NOT is overwritting using Webmin, I think that som dark magic is added to Virtualmin. Why not Webmin? Why Virtualmin?

It’s not Virtualmin, it’s the template in use by your provider most likely.
In any case, Virtualmin also installs BIND which should be a working resolver on your system listening to
Did you by any chance disable BIND?

Adding “stuff” to work-around the problem instead of fixing it is hardly ever a good idea.

Virtualmin only modifies resolvers on install, but it tries to do it in the right place…so, if your system is using dhcp, it gets appended to the dhcp name servers settings (which will get applied to /etc/resolv.conf on every reboot or network restart). If it’s resolv.conf, it changes resolv.conf, but only once.

If you aren’t using a local BIND, you don’t need it to point to (though it is now common to do so, even if you aren’t…most systems default to having a local caching resolver of some sort and so is the name server in those cases, even without Virtualmin changing anything).

We’re debating changing this and giving up on trying to “fix” the resolvers during install, as the landscape has gotten so complicated and it’s so easy to get it wrong. In the good old days we could count on there not already being a local resolver on a server installation of our supported OSes…that’s less common now. And with VMs being so common, and with it being so much more common for people to not use local DNS, it’s becoming maybe more trouble than it’s worth just to have site previews work (and a few other minor features).



Hosters / providers do at reboots sometimes / often overwrite resolv.conf

So if virtualmin has fixed that for you , then that fix is undone… :frowning:

If you know when they change network things , or you know yourself howto fix that.
You can protect resolv.conf against that overwrite with “chatrr” command in CLI interface

For openstack using cloudinit you should i guess. :wink:

You often need a kind of combination, that what OS/CP network config tell you and the hoster part, so take care of both.

How do I find out?

Only you know what you’ve done to the system.

ss -tulnp | grep :53
systemctl status bind9

This will show if BIND is running and listening.

> ss -tulnp | grep :53
udp     UNCONN   0        0      *      users:(("named",pid=709,fd=515))                                               
udp     UNCONN   0        0   *      users:(("named",pid=709,fd=514))                                               
udp     UNCONN   0        0       *      users:(("named",pid=709,fd=513))                                               
udp     UNCONN   0        0                   [::]:53                [::]:*      users:(("named",pid=709,fd=512))                                               
tcp     LISTEN   0        10     *      users:(("named",pid=709,fd=24))                                                
tcp     LISTEN   0        10   *      users:(("named",pid=709,fd=23))                                                
tcp     LISTEN   0        10      *      users:(("named",pid=709,fd=22))                                                
tcp     LISTEN   0        10                  [::]:53                [::]:*      users:(("named",pid=709,fd=21))
> systemctl status bind9
â—Ź bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-10-27 13:53:23 CEST; 19h ago
     Docs: man:named(8)
 Main PID: 709 (named)
    Tasks: 4 (limit: 2359)
   Memory: 26.9M
   CGroup: /system.slice/bind9.service
           └─709 /usr/sbin/named -u bind

How does this affect resolv.conf?

I just tested another VPS (only Webmin) and the bind9 was not installed. Where bind9 is absent, the apt-get update work

systemctl status bind9
Unit bind9.service could not be found.

Uh is on that one then a resolv.conf if yes what is in it.?

Also is on both a firewall active?

(So the virtualmin defaults are mostly with bind and then doing as @Joe did write above for network.)

Out of my curiosity, did you mean update or upgrade? Also, at a command prompt, did you try sudo apt upgrade?

Normal update within Debian 10

Thank you very much. I just usually use upgrade because I wish to install any necessary updates as I go. I get the same information with upgrade plus the additional benefits of applying any available changes when available.

In any case, when confronted with the inability of a command not to work as expected, one might just go to the lowest common denominator to find the blockage. Opening a command prompt directly should satisfy that question.

As Joe pointed out, things can get very complicated. In that case, going direct thru the 'Net with a command-line entry will tell you where the blockage is located. You were on the right track with your third post above.

Good luck.

I really don’t understand why folks don’t just let Virtualmin do it all. I haven’t logged on to my actual server terminal in months. I check the Virtualmin panel from time to time and it handles all the updates for everything, even a Plex server I have running on it.

It’s never failed.

Yeah I do too. Let Virtualmin take the lead and sort. It wont always get it right but way better than my own effort and skills. From what I can see, many start to have problems when using 3rd party DNS, VMs and network bridging. Some providers also got weird ways of dealing with network routing.

1 Like