Project

General

Profile

Bug #14436

Incorrect handling of resolv.conf generation and other network issues

Added by Vaibhav Chauhan over 3 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Important
Assignee:
William Grzybowski
Category:
Middleware
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

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.


Related issues

Copied from FreeNAS - Bug #14415: Incorrect handling of resolv.conf generation and other network issuesResolved2016-04-01

Associated revisions

Revision 00b150e3 (diff)
Added by William Grzybowski almost 3 years ago

feat(middlewared): sync dns method using resolvconf

Ticket: #14436

Revision 33b614a0 (diff)
Added by William Grzybowski almost 3 years ago

fix(middlewared): use dns.sync instead of generate_resolv_conf.py

Ticket: #14436

Revision 868d6131 (diff)
Added by William Grzybowski almost 3 years ago

fix(middlewared): typo in midclt

Ticket: #14436

History

#1 Updated by Vaibhav Chauhan over 3 years ago

  • Copied from Bug #14415: Incorrect handling of resolv.conf generation and other network issues added

#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.

#3 Updated by Vaibhav Chauhan over 3 years ago

  • Target version changed from 261 to 9.10-U1

#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.

#5 Updated by Vaibhav Chauhan about 3 years ago

  • Priority changed from Nice to have to Important
  • Target version changed from Unspecified to 9.10.2

BRB: suraj please update ticket.

#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.

#7 Updated by William Grzybowski about 3 years ago

  • Status changed from Unscreened to Screened

#8 Updated by William Grzybowski almost 3 years ago

  • Status changed from Screened to 19

#9 Updated by William Grzybowski almost 3 years ago

  • Status changed from 19 to Needs Developer Review

#10 Updated by William Grzybowski almost 3 years ago

  • Assignee changed from William Grzybowski to Josh Paetzel

#11 Updated by Josh Paetzel over 2 years ago

  • Status changed from Needs Developer Review to Reviewed
  • Assignee changed from Josh Paetzel to William Grzybowski

#12 Updated by Vaibhav Chauhan over 2 years ago

  • Status changed from Reviewed to Ready For Release

#13 Updated by Dru Lavigne over 1 year ago

  • Status changed from Ready For Release to Resolved

Also available in: Atom PDF