Incorrect handling of resolv.conf generation and other network issues
This is a ticket to track the bugs found in
generate_resolv_conf as well as the way in which the
GlobalConfigurationForm executes the restarting of various network services and how it writes the nameservers to the resolv.conf or not.
Made a ticket related to 14415 for continuing work on 9.10-STABLE.
fix(middlewared): use dns.sync instead of generate_resolv_conf.py
#2 Updated by Suraj Ravichandran over 3 years ago
- Priority changed from Blocks Until Resolved to Critical
Given that this works for now with the fix we pushed last week I am not inclined to make a change this close to the SU, thus marking critical and not Blocks Until Resolved.
Those edge cases persist still though.
#4 Updated by Suraj Ravichandran about 3 years ago
- Priority changed from Critical to Nice to have
- Target version changed from 9.10-U1 to Unspecified
It was decided that we just display a warning sign when the user moves from any static to dynamic only network configuration stating this: "These static to dynamic changes require your FreeNAS/TrueNAS box to be restarted. Do you still wish to continue? Yes/No".
Moving priority accordingly.
#6 Updated by Suraj Ravichandran about 3 years ago
- Status changed from Screened to Unscreened
- Assignee changed from Suraj Ravichandran to William Grzybowski
The concern here was the fact that if the user had a default gateway specified manually and then took it out and hit save OR did the same with a dns server (like took out the manually specified ones and then hit save) the auto dhcp assigned values for these fields do not kick in and either a reboot or shell intervention is required.
This can be mitigated in several ways but the most efficient way to do this would be to fold it into the "apply network delta changes and not restart the entire network" approach that has been planned already.
Thus, assigning it to @William. Will also ping him on slack to clarify anything if my above description comes across as being totally vague.