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…
Generated by NetworkManager
search (hereyourmaindomainfor server so no hostname but domain) (this without () )
nameserver 127.0.0.1
nameserver 8.8.8.8
nameserver 1.1.1.1
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
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 127.0.0.1.
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 127.0.0.1 (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 127.0.0.1 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…
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.
You often need a kind of combination, that what OS/CP network config tell you and the hoster part, so take care of both.
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.
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.
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.
