Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/save dns records to hosts #172

Open
wants to merge 15 commits into
base: develop
Choose a base branch
from

Conversation

dnmurray
Copy link
Contributor

Unix only so far. Need to do some research to support Windows (and someone to test).

febbraro and others added 14 commits February 16, 2017 14:44
Corrected a few more references to rig, and elaborated the build script.
* Add explicit privilege prompt to improve sudo UX (phase2#138)

* Explicitly prompt for privilege escallation

* Remove password prompt part of privilege message

* Expand sudo detection.

* Tidy up timing issues.

* Consolidate messaging and avoid newline in verbose.

* Cleanup ToString, sudo contains, cover more exec methods.

* Lint does not catch all of fmt.

* Remove unnecessary password prompt from networking cleanup.

* Remove color reset and cat /dev/null to clear route text.

* trying a different approach to requesting for admin privs (phase2#144)
@febbraro
Copy link
Member

On Windows the file is C:\Windows\System32\drivers\etc\hosts

}

printDNSRecords(records)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you do a save or remove you likely don't want the records printed out too so maybe we only print the records if save or remove have not been specified

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They always return if they do a save or remove. So it just falls through to the default if they don't specify either.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OH yeah. ha. You got it.

newHostEntries := stripDNS(oldHostEntries)
// records.String does the formatting, so convert both to a string
oldHosts := strings.Join(oldHostEntries, "\n")
newHosts := strings.Join(newHostEntries, "\n") + "\n" +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could also do something like this...

fmt.Sprintf(`%s
%s
%s`, x, y, z)

to get the newlines you want.

@febbraro
Copy link
Member

The other thing that comes to mind here is how many people may get hung up because they have entries in their hosts files that they haven't removed. Maybe add a doctor check for DNS entries in /etc/hosts and let the user know that? Or do you think this is really a non issue?

@dnmurray
Copy link
Contributor Author

I can add a check that the rows are there. It's easy enough to look for, since I'm using the pre/postamble. If you do a --save and the rows are already they, they get removed and recreated.

type DNSRecordsList []*DNSRecord

const (
unixHostsPreamble = "##+++ added by rig"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you'll use this regardless of the underlying os as markers for starting/removing items so perhaps just call this hostsPreamble

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Thanks.

for id, value := range dnsdockMap {
record := value.(map[string]interface{})
record["Id"] = id
records := make([]*DNSRecord, 0, 20)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interested in your thoughts behind the use of the capacity argument here. As near as I can tell this doesn't set any upper bound on the size of the array though I had to write a quick test to make sure. Is the initial capacity you picked arbitrary (both here and below where you used 10) or is there something behind that particular value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Completely arbitrary. Yes, when accumulating the array contents via append() more space will be allocated if needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that it's a dynamic array perhaps just drop the capacity argument here and anywhere it doesn't have an obvious purpose. This is to prevent confusing anyone in the future about why it is there, how it got picked, does it actually result in enforced bounds, etc? Alternatively, comment something to the effect of what I think may be true about it:

// capacity picked arbitrarily with a size likely to prevent need to reallocate underlying arrays while appending items in most cases

I also presume that has some potential performance benefit though at the scales here I think it's unobservable.

If that comment isn't accurate I'd be interested in what the benefits are of declaring a capacity are in the case where append is going to be used. When using copy it's an obvious useful item to restrict the number of items you want from a potentially larger array.

Thanks for the pointers as I drag myself deeper into go.

@dnmurray
Copy link
Contributor Author

Can this be tagged "In Progress". Adding Windows support.

@febbraro
Copy link
Member

This has a bunch of merges in it. Do you need to rebase on develop?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants