/etc/resolv.conf empty after DA update

P

patrickkasie

Verified User
Joined
Sep 21, 2021
Messages
226
Location
Een echte Hollander
Dear DirectAdmin forum,

I update our servers through the CLI as root user. I'm using the following commands:
Code: 
cd /usr/local/directadmin/custombuild
./build update_da
./build update
./build versions
./build update_versions
Since July 22nd, every time I update all my servers, there's a couple of them who end up with an empty /etc/resolv.conf, resulting in the inability to request SSL certificates, desynchronised server time and more that I don't know about. See images below. VPS10 is what happens after the update, VPS04 is what happens before the update. Not all servers experience this problem, and they're all CentOS7 or AlmaLinux 8. There does not seem to be a pattern deciding when the name servers get removed or not, except for the file being updated after performing the update on said servers.
 

Attachments

  • mRemoteNG_P1YvjZsqBw.png
    mRemoteNG_P1YvjZsqBw.png
    10.5 KB · Views: 9
  • mRemoteNG_JxbXwq5ylW.png
    mRemoteNG_JxbXwq5ylW.png
    13.5 KB · Views: 9
That is odd. Because with Centos 7 this should not happen unless NetworkManager is used there too. However, on Alma 8 and 9 it's Networkmanager which will empty them out for you, not DA, because DA does not touch /etc/resolv.conf files.
But on the network restart, it's the NetworkManager who cleans them out.

Either fill in the proper values the proper way in NetworkManager so it writes the correct one. Or disable NetworkManager from messing with your resolv.conf file.

I use the latter method.
Edit /etc/NetworkManager/NetworkManager.conf and add dns=none under the main tab, like this:
Code: 
[main]
dns=none

After that it should not touch your resolv.conf file anymore.
 
The file /etc/NetworkManager/NetworkManager.conf hasn't been touched since Nov 16 2020. Why would it suddenly act this way? This is on one of the affected CentOS7 servers. All of them are the same among the CentOS7 servers. The same thing goes among all of the AlmaLinux 8 servers. I will add dns=none to all servers on every /etc/NetworkManager/NetworkManager.conf, both CentOS7 and AlmaLinux 8, but it's still strange that it's only happening now.
 
patrickkasie said:
Why would it suddenly act this way?
Click to expand...
Maybe due to an OS update which "fixes" the not working. I don't know. In my case on all Alma 8 and 9 servers it happened almost instantly.
And the screenshots shows me NetworkManager created the /etc/resolv.conf file so you can be sure it's NetworkManager.
I also never had it happen on Centos 7 servers, but probably I had no Network Manager installed or it was disabled, not sure. Or... it was just not working as should be. Maybe that's the reason it's happening now.

As for Alma 8 I don't know. As said in my case it almost happend instantly after install of DA, then the bind and network restarts and NetworkManager instantly changed it.

DA reallly does not touch the resolv.conf file.
But indeed odd that NM suddenly starts messing with things if it didn't before. But if you disable it like I said, you'll see it isn't DA but NM who did, because the issue will be over. ;)
 
Hi Richard,

You are doing D.A. a favor by answering clients.
The LLH thread has closed, so everything is now 'fine and dandy'? (goed en wel)?
You could as wel answer Patrick in Dutch then .. ..
You are too good for this world .. .. ..

PS: option "dns=none" is not in my /etc/NetworkManager/NetworkManager.conf (Alma9). I added it, thanks for the tip.
 
sec-is said:
You are too good for this world .. .. ..
Click to expand...
Thanks for the compliment. ;)

I have stopped a little while, but others answered also anyway. And I thought by not answering others, I don't really harm DA but harm the others more and it won't make any difference for DA's decision.

Not everything is fine and well, but I don't think any company would allow any thread open in which people can cope against them by law. So once this was going on, I understand them closing the thread for that reason. Most company's wouldn't allow a negative thread like that about the company at all, even without the legal stuff.
And the thread has been going on for over a year, nothing changes, so I guess the lifetime licences are down the drain anyway more or less starting with the first EOL stuff.

As for the tip, you're welcome ofcourse!
 
Everybody has it's own methods. It's also possible to use the official method. Using chattr is also possible yes.
 
I have seen other programs not related to DA modify it. That is why I choose chattr. This prevents any program or script or whatever from modifying it.
 
This sadly did not solve it.

After updating and rebooting the server using my standard routine of commands, it still updates the /etc/resolv.conf
The following commands are used, even though the first one doesn't work because I use a script to execute the updates. No, there's nothing more to the script than this:

Code: 
yum update -y
cd /usr/local/directadmin/custombuild
./build update_da
cp -f custom_versions.txt custom_versions.txt-pre-update || touch custom_versions.txt
cp -f versions.txt versions.txt-pre-update (so if something goes wrong I can still revert back to the old versions, proved very useful in the past)
./build update
./build versions
./build update_versions
reboot

Is this supposed to rewrite the /etc/resolve.conf file? Or the reboot? The timezone as it has been set in DA is Europe/Amsterdam. I have just become aware that executing these steps as root does allow the script or the reboot to edit the file, but the option dns=none should have prevented this as told in the first reply by Richard
 

Attachments

  • mRemoteNG_WObm72PupF.png
    mRemoteNG_WObm72PupF.png
    76.8 KB · Views: 2
floyd said:
I don't know what you are trying to say. ll has nothing to do with chattr so I am not sure why you are comparing the two. To see attributes of a file you have to use the lsattr command.
Click to expand...
You're right. I assumed chmod was the only way to make sure files would or would not get edited. Now that it has become immutable after a literal 1 minute lookup, it should be correct. I did not know about this extra layer of rights of files and the likes. Thank you for that!
 
Do you use DHCP too by any chance, maybe for internal ip's? If yes than that can be the cause.
Normally these are used:
Code: 
dns=none
rc-manager=unmanaged
however dns=none normally implies the rc-manager=unmanaged.

If you want to investigate why this happens or who is doing this, you can try to add that second line.
If you use DHCP still, then add this to your dhcpcd.conf file:
nohook resolv.conf, wpa_supplicant
or just disable dhcp if you don't use it.

If you just want to get rid of any changes no matter what, use the chattr command.

I never had this issue on any server after adjusting the NetworkManager.
 
t
Richard G said:
So who says DA is touching it? He thinks that, there is no proof.
DA does not touch the /etc/resolv.conf because there would be loads more problems, that's also simple.
Click to expand...
When i run a new install it modified after the setup runs.... and it fails because it cant resolve anymore.... so yeah.... and no DHCP.

Sooooooo...
 
Imtek said:
Sooooooo...
Click to expand...
So did you reboot after the install? Because I've experienced this also, but this was NetworkManager doing it.
And now it's claimed it touches after an update, sooooo.... not proof enough.

Tip: Try setting the mentioned commands to NetworkManager and then do the DA install afterwards... done it couple of times like this now and no clearing of the resolv.conf anymore, so what does that tell you?

I wouldn't know what DA has to to with the /etc/resolv.conf anyways, but if DA indeed would touch it, or rather clear it, then it's clearly a bug.
Maybe @fln can shed some light on this, but I don't believe it's DA doing this.
 
You must log in or register to reply here.
Back
Top