[GH-ISSUE #24] Goodhosts' rewrite of the hosts file renders MAMP incapable of managing its entries #13

Open
opened 2026-03-02 05:09:09 +03:00 by kerem · 30 comments
Owner

Originally created by @theMikeD on GitHub (Dec 28, 2020).
Original GitHub issue: https://github.com/goodhosts/cli/issues/24

I am running MAMP Pro and VVV simultaneously, and sometimes concurrently. When MAMP Pro has first crack at the /etc/hosts file, it ends up looking like this:

127.0.0.1	scratch.test	# MAMP PRO - Do NOT remove this entry!
::1		scratch.test	# MAMP PRO - Do NOT remove this entry!
127.0.0.1	clean.test	# MAMP PRO - Do NOT remove this entry!
::1		clean.test	# MAMP PRO - Do NOT remove this entry!
127.0.0.1	cnmd.test	# MAMP PRO - Do NOT remove this entry!
::1		cnmd.test	# MAMP PRO - Do NOT remove this entry!
127.0.0.1	boilerplate.test	# MAMP PRO - Do NOT remove this entry!
::1		boilerplate.test	# MAMP PRO - Do NOT remove this entry!
127.0.0.1	macster.local	# MAMP PRO - Do NOT remove this entry!
::1		macster.local	# MAMP PRO - Do NOT remove this entry!

etc etc. Adding and removing hosts via MAMP Pro works correctly, and shutting down MAMP Pro removes all entries it controls. All fine.

When I fire up MAMP Pro and then fire up VVV, /etc/hosts gets rewritten so that I end up with this

::1 boilerplate.test clean.test cnmd.test macster.local scratch.test # MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!
127.0.0.1 boilerplate.test clean.test cnmd.test macster.local scratch.test # MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!  MAMP PRO - Do NOT remove this entry!
192.168.50.4 vvv vvv.test rfa.test # VAGRANT: 32549be2774dded0939569e71b56d8f1 (default) / 465e8518-e2b5-4ae0-9348-e56e8662ab2d
255.255.255.255 broadcasthost

IOW they have gone from one-per-line pairs to a single entry. This rewrite prevents MAMP from being able to manage its entries.

As technically correct as this may be, this is a bad scene. Is there a way to have GH just do its thing without modifying anything else?

Originally created by @theMikeD on GitHub (Dec 28, 2020). Original GitHub issue: https://github.com/goodhosts/cli/issues/24 I am running MAMP Pro and VVV simultaneously, and sometimes concurrently. When MAMP Pro has first crack at the `/etc/hosts` file, it ends up looking like this: ``` 127.0.0.1 scratch.test # MAMP PRO - Do NOT remove this entry! ::1 scratch.test # MAMP PRO - Do NOT remove this entry! 127.0.0.1 clean.test # MAMP PRO - Do NOT remove this entry! ::1 clean.test # MAMP PRO - Do NOT remove this entry! 127.0.0.1 cnmd.test # MAMP PRO - Do NOT remove this entry! ::1 cnmd.test # MAMP PRO - Do NOT remove this entry! 127.0.0.1 boilerplate.test # MAMP PRO - Do NOT remove this entry! ::1 boilerplate.test # MAMP PRO - Do NOT remove this entry! 127.0.0.1 macster.local # MAMP PRO - Do NOT remove this entry! ::1 macster.local # MAMP PRO - Do NOT remove this entry! ``` etc etc. Adding and removing hosts via MAMP Pro works correctly, and shutting down MAMP Pro removes all entries it controls. All fine. When I fire up MAMP Pro and then fire up VVV, `/etc/hosts` gets rewritten so that I end up with this ``` ::1 boilerplate.test clean.test cnmd.test macster.local scratch.test # MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! 127.0.0.1 boilerplate.test clean.test cnmd.test macster.local scratch.test # MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! MAMP PRO - Do NOT remove this entry! 192.168.50.4 vvv vvv.test rfa.test # VAGRANT: 32549be2774dded0939569e71b56d8f1 (default) / 465e8518-e2b5-4ae0-9348-e56e8662ab2d 255.255.255.255 broadcasthost ``` IOW they have gone from one-per-line pairs to a single entry. This rewrite prevents MAMP from being able to manage its entries. As technically correct as this may be, this is a bad scene. Is there a way to have GH just do its thing without modifying anything else?
Author
Owner

@luthermonson commented on GitHub (Dec 28, 2020):

i dont think you can use the --clean functionality with a rig like mamp then, the only way to get here is through a clean flag right? i am not missing something that got you here via other use?

<!-- gh-comment-id:751811070 --> @luthermonson commented on GitHub (Dec 28, 2020): i dont think you can use the `--clean` functionality with a rig like mamp then, the only way to get here is through a clean flag right? i am not missing something that got you here via other use?
Author
Owner

@tomjn commented on GitHub (Dec 28, 2020):

I think this needs migrating to the vagrant repo at https://github.com/goodhosts/vagrant

<!-- gh-comment-id:751825720 --> @tomjn commented on GitHub (Dec 28, 2020): I think this needs migrating to the `vagrant` repo at https://github.com/goodhosts/vagrant
Author
Owner

@luthermonson commented on GitHub (Dec 28, 2020):

ohhh that makes sense, ill copy/paste and link it and close this

<!-- gh-comment-id:751826093 --> @luthermonson commented on GitHub (Dec 28, 2020): ohhh that makes sense, ill copy/paste and link it and close this
Author
Owner

@Mte90 commented on GitHub (Dec 29, 2020):

To me the issue is not just the plugin that does a clean but the fact that the clean command, cleans all the file and just the parts that are involved with goodhosts.

Clean command was implemented to avoid multiple injection of the same rule by goodhosts as a previous ticket so is a problem in both the projects @luthermonson

<!-- gh-comment-id:752021430 --> @Mte90 commented on GitHub (Dec 29, 2020): To me the issue is not just the plugin that does a clean but the fact that the clean command, cleans all the file and just the parts that are involved with goodhosts. Clean command was implemented to avoid multiple injection of the same rule by goodhosts as a previous ticket so is a problem in both the projects @luthermonson
Author
Owner

@luthermonson commented on GitHub (Dec 29, 2020):

you think there should be a #goodhosts comment or something and just keep everything 100% separate from everyone else?

<!-- gh-comment-id:752195492 --> @luthermonson commented on GitHub (Dec 29, 2020): you think there should be a `#goodhosts` comment or something and just keep everything 100% separate from everyone else?
Author
Owner

@Mte90 commented on GitHub (Dec 29, 2020):

yes in this way the user can use clean without worrying.

<!-- gh-comment-id:752195748 --> @Mte90 commented on GitHub (Dec 29, 2020): yes in this way the user can use clean without worrying.
Author
Owner

@luthermonson commented on GitHub (Dec 29, 2020):

@Mte90 @theMikeD let's do it, if we do some sort of #MANAGED BY GOODHOSTS comment block and only change entries in there it would make the most sense but i feel this requires a 1.1.x version bump, agree?

<!-- gh-comment-id:752198007 --> @luthermonson commented on GitHub (Dec 29, 2020): @Mte90 @theMikeD let's do it, if we do some sort of `#MANAGED BY GOODHOSTS` comment block and only change entries in there it would make the most sense but i feel this requires a 1.1.x version bump, agree?
Author
Owner

@Mte90 commented on GitHub (Dec 29, 2020):

Yes to me is good so I can do a new release of the plugin with that and add a flag to enable or not the clean at all.

<!-- gh-comment-id:752198358 --> @Mte90 commented on GitHub (Dec 29, 2020): Yes to me is good so I can do a new release of the plugin with that and add a flag to enable or not the clean at all.
Author
Owner

@tomjn commented on GitHub (Dec 29, 2020):

This sounds good!

<!-- gh-comment-id:752207645 --> @tomjn commented on GitHub (Dec 29, 2020): This sounds good!
Author
Owner

@theMikeD commented on GitHub (Jan 9, 2021):

Whats the next step?

<!-- gh-comment-id:757342252 --> @theMikeD commented on GitHub (Jan 9, 2021): Whats the next step?
Author
Owner

@luthermonson commented on GitHub (Jan 11, 2021):

find time to add the feature :D PRs welcome~

<!-- gh-comment-id:758200613 --> @luthermonson commented on GitHub (Jan 11, 2021): find time to add the feature :D PRs welcome~
Author
Owner

@tomjn commented on GitHub (Jan 11, 2021):

Luther I think the problem is less time and willingness and more that they
don’t know how to do it, I know that’s definitely the case here.

What would such a PR look like?

On Mon, 11 Jan 2021 at 20:22, Luther Monson notifications@github.com
wrote:

find time to add the feature :D PRs welcome~


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/goodhosts/cli/issues/24#issuecomment-758200613, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAOLZ55NORZI7TLYW4ORJLSZNMYLANCNFSM4VMGYQEQ
.

<!-- gh-comment-id:758206011 --> @tomjn commented on GitHub (Jan 11, 2021): Luther I think the problem is less time and willingness and more that they don’t know how to do it, I know that’s definitely the case here. What would such a PR look like? On Mon, 11 Jan 2021 at 20:22, Luther Monson <notifications@github.com> wrote: > find time to add the feature :D PRs welcome~ > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/goodhosts/cli/issues/24#issuecomment-758200613>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAOLZ55NORZI7TLYW4ORJLSZNMYLANCNFSM4VMGYQEQ> > . >
Author
Owner

@tomjn commented on GitHub (Jan 13, 2021):

@luthermonson any update or technical direction? You have willing contributors with the time to make the change, who don't know what to do. I'd really like to be able to write a PR but what would that PR look like?

<!-- gh-comment-id:759494855 --> @tomjn commented on GitHub (Jan 13, 2021): @luthermonson any update or technical direction? You have willing contributors with the time to make the change, who don't know what to do. I'd really like to be able to write a PR but what would that PR look like?
Author
Owner

@luthermonson commented on GitHub (Jan 13, 2021):

@tomjn this is what i want.. open to feedback

  1. all code for doing this should be in the cli, the hostsfile package should just be to parse a hosts file to types. this is logic around what to do with the hostsfile after that is done so this code should be here in this repo, can try doing a first round of this have a line type that uses hostsfile.Line and includes a bool which is we check if we manage the line or not.
  2. easiest thing is probably a string to match in comment per line like MAMP does, for example as long as it contains goodhosts in the comment we assume it was meant for our cli, just need a something simple like strings.Contains("goodhosts", comment). e.g. we'd manage all of these lines
127.0.0.1 myhost anotherhost #goodhosts
192.168.0.2 dev-server1 #my comment here goodhosts
192.168.0.3 dev-server2 #goodhosts my comment here
  1. make sure when we add an entry with the add subcommand we need to make sure the comment gets put in place as well
  2. might find it annoying if the goodhosts managed lines are all over the file, might want clean to group them together
  3. dont forget the tests!
<!-- gh-comment-id:759600563 --> @luthermonson commented on GitHub (Jan 13, 2021): @tomjn this is what i want.. open to feedback 1. all code for doing this should be in the cli, the hostsfile package should just be to parse a hosts file to types. this is logic around what to do with the hostsfile after that is done so this code should be here in this repo, can try doing a first round of this have a line type that uses hostsfile.Line and includes a bool which is we check if we manage the line or not. 2. easiest thing is probably a string to match in comment per line like MAMP does, for example as long as it contains `goodhosts` in the comment we assume it was meant for our cli, just need a something simple like `strings.Contains("goodhosts", comment)`. e.g. we'd manage all of these lines ``` 127.0.0.1 myhost anotherhost #goodhosts 192.168.0.2 dev-server1 #my comment here goodhosts 192.168.0.3 dev-server2 #goodhosts my comment here ``` 3. make sure when we add an entry with the add subcommand we need to make sure the comment gets put in place as well 4. might find it annoying if the goodhosts managed lines are all over the file, might want clean to group them together 5. dont forget the tests!
Author
Owner

@theMikeD commented on GitHub (Jan 15, 2021):

Maybe we can just revert the clean imperative until there is a way to turn it off?

<!-- gh-comment-id:761185789 --> @theMikeD commented on GitHub (Jan 15, 2021): Maybe we can just revert the clean imperative until there is a way to turn it off?
Author
Owner

@tomjn commented on GitHub (Jan 16, 2021):

@theMikeD that doesn't make sense in the context of this repo, for Goodhosts CLI, it would be easier to not use --clean than it would be to remove the feature.

I think there's been some misunderstanding as to what goodhosts is on your part:

  • goodhosts cli, a golang command line program for adding and removing things from the hosts file
  • vagrant-goodhosts, a vagrant plugin that uses goodhosts to add hosts as requested by a vagrant project
  • VVV, a vagrant project that uses vagrant goodhosts in place of vagrant hostsupdater

This is the goodhosts cli repo, so reverting the --clean parameter means removing that feature. Unless you meant make vagrant-goodhosts not specify --clean? Because goodhosts only cleans when the --clean parameter is passed

<!-- gh-comment-id:761280639 --> @tomjn commented on GitHub (Jan 16, 2021): @theMikeD that doesn't make sense in the context of this repo, for Goodhosts CLI, it would be easier to not use `--clean` than it would be to remove the feature. I think there's been some misunderstanding as to what goodhosts is on your part: - **goodhosts cli**, a golang command line program for adding and removing things from the hosts file - **vagrant-goodhosts**, a vagrant plugin that uses goodhosts to add hosts as requested by a vagrant project - **VVV**, a vagrant project that uses vagrant goodhosts in place of vagrant hostsupdater This is the goodhosts cli repo, so reverting the `--clean` parameter means removing that feature. Unless you meant make `vagrant-goodhosts` not specify `--clean`? Because goodhosts only cleans when the `--clean` parameter is passed
Author
Owner

@theMikeD commented on GitHub (Jan 16, 2021):

I'm becoming a pro at posting bugs to the wrong repo. Please move this issue elsewhere if you deem it appropriate.

Unless you meant make vagrant-goodhosts not specify --clean?

Yes, this. As I understand it, doing so isn't something I can control with a config file.

<!-- gh-comment-id:761304514 --> @theMikeD commented on GitHub (Jan 16, 2021): I'm becoming a pro at posting bugs to the wrong repo. Please move this issue elsewhere if you deem it appropriate. > Unless you meant make `vagrant-goodhosts` not specify `--clean`? Yes, this. As I understand it, doing so isn't something I can control with a config file.
Author
Owner

@tomjn commented on GitHub (Jan 16, 2021):

You posted in the right repo, but that particular request was for a different piece of software. IIRC @Mte90 has already fixed and merged a PR that makes it configurable and off by default

<!-- gh-comment-id:761623081 --> @tomjn commented on GitHub (Jan 16, 2021): You posted in the right repo, but that particular request was for a different piece of software. IIRC @Mte90 has already fixed and merged a PR that makes it configurable and off by default
Author
Owner

@tomjn commented on GitHub (Jan 16, 2021):

As for this feature, I think these semantics make sense if the CLI is used in conjunction with a --namespace="" parameter.

When adding a host:

  • if the host already exists
    • if it exists on a line without the namespace comment on the end
      • error message + bad error code
    • if it exists on a line with the namespace comment
      • remove from file and add on a new line if the IP is different with namespace comment
      • do nothing if the IP is the same
  • if it does not exist
    • add on a new line with namespace comment

When removing a host:

  • if it exists on a line without the namespace comment on the end
    • error message + bad error code
  • if it exists on a line with the namespace comment
    • remove from file

Additionally, the namespace parameter would allow rival namespaces, as well as the ability for us to do things like:

goodhosts remove cnmd.test --namespace="MAMP PRO - Do NOT remove this entry!"
<!-- gh-comment-id:761623945 --> @tomjn commented on GitHub (Jan 16, 2021): As for this feature, I think these semantics make sense if the CLI is used in conjunction with a `--namespace=""` parameter. When adding a host: - if the host already exists - if it exists on a line without the namespace comment on the end - error message + bad error code - if it exists on a line with the namespace comment - remove from file and add on a new line if the IP is different with namespace comment - do nothing if the IP is the same - if it does not exist - add on a new line with namespace comment When removing a host: - if it exists on a line without the namespace comment on the end - error message + bad error code - if it exists on a line with the namespace comment - remove from file Additionally, the namespace parameter would allow rival namespaces, as well as the ability for us to do things like: ```sh goodhosts remove cnmd.test --namespace="MAMP PRO - Do NOT remove this entry!" ```
Author
Owner

@tomjn commented on GitHub (Jan 16, 2021):

all code for doing this should be in the cli, the hostsfile package should just be to parse a hosts file to types. this is logic around what to do with the hostsfile after that is done so this code should be here in this repo, can try doing a first round of this have a line type that uses hostsfile.Line and includes a bool which is we check if we manage the line or not.

This seems sensible

easiest thing is probably a string to match in comment per line like MAMP does, for example as long as it contains goodhosts in the comment we assume it was meant for our cli, just need a something simple like strings.Contains("goodhosts", comment). e.g. we'd manage all of these lines

I think we should allow the namespace to be configurable from the CLI parameter for maximum flexibility, then search for # namespace \n or equivalent

<!-- gh-comment-id:761624494 --> @tomjn commented on GitHub (Jan 16, 2021): > all code for doing this should be in the cli, the hostsfile package should just be to parse a hosts file to types. this is logic around what to do with the hostsfile after that is done so this code should be here in this repo, can try doing a first round of this have a line type that uses hostsfile.Line and includes a bool which is we check if we manage the line or not. This seems sensible > easiest thing is probably a string to match in comment per line like MAMP does, for example as long as it contains goodhosts in the comment we assume it was meant for our cli, just need a something simple like strings.Contains("goodhosts", comment). e.g. we'd manage all of these lines I think we should allow the namespace to be configurable from the CLI parameter for maximum flexibility, then search for `# namespace \n` or equivalent
Author
Owner

@Mte90 commented on GitHub (Feb 22, 2021):

any updates for this @luthermonson?

<!-- gh-comment-id:783374836 --> @Mte90 commented on GitHub (Feb 22, 2021): any updates for this @luthermonson?
Author
Owner

@luthermonson commented on GitHub (Feb 22, 2021):

oh thanks for the ping. this fell off my radar. adding it to my task list and ill try and get to it this week

<!-- gh-comment-id:783573175 --> @luthermonson commented on GitHub (Feb 22, 2021): oh thanks for the ping. this fell off my radar. adding it to my task list and ill try and get to it this week
Author
Owner

@tomjn commented on GitHub (Mar 22, 2021):

@theMikeD latest goodhosts vagrant plugin removed the clean operation a few months ago

<!-- gh-comment-id:804366515 --> @tomjn commented on GitHub (Mar 22, 2021): @theMikeD latest goodhosts vagrant plugin removed the clean operation a few months ago
Author
Owner

@Mte90 commented on GitHub (Apr 2, 2021):

@luthermonson just a ping again :-D

<!-- gh-comment-id:812581246 --> @Mte90 commented on GitHub (Apr 2, 2021): @luthermonson just a ping again :-D
Author
Owner

@luthermonson commented on GitHub (Apr 5, 2021):

oi vey

<!-- gh-comment-id:813710267 --> @luthermonson commented on GitHub (Apr 5, 2021): oi vey
Author
Owner

@Mte90 commented on GitHub (May 11, 2021):

and it is time for another ping @luthermonson :-D

<!-- gh-comment-id:838912002 --> @Mte90 commented on GitHub (May 11, 2021): and it is time for another ping @luthermonson :-D
Author
Owner

@luthermonson commented on GitHub (Jun 3, 2021):

missed this ping... sorry. im bad at getting this feature done.

<!-- gh-comment-id:853687794 --> @luthermonson commented on GitHub (Jun 3, 2021): missed this ping... sorry. im bad at getting this feature done.
Author
Owner

@Mte90 commented on GitHub (Jun 28, 2021):

it's me again :-D
I don't know Go otherwise I will try to implement it.

<!-- gh-comment-id:869858210 --> @Mte90 commented on GitHub (Jun 28, 2021): it's me again :-D I don't know Go otherwise I will try to implement it.
Author
Owner

@tomjn commented on GitHub (Oct 1, 2023):

is this still an issue with the new release? I saw test cases with MAMP examples were added to the hostsfile repo prior to 1.1.1 release

<!-- gh-comment-id:1742111863 --> @tomjn commented on GitHub (Oct 1, 2023): is this still an issue with the new release? I saw test cases with MAMP examples were added to the hostsfile repo prior to 1.1.1 release
Author
Owner

@luthermonson commented on GitHub (Oct 2, 2023):

it's not fixed yet, i grabbed the mamp hosts file to try and test it eventually as i started keeping default hosts files to write more tests against

<!-- gh-comment-id:1742362633 --> @luthermonson commented on GitHub (Oct 2, 2023): it's not fixed yet, i grabbed the mamp hosts file to try and test it eventually as i started keeping default hosts files to write more tests against
Sign in to join this conversation.
No labels
bug
bug
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/cli#13
No description provided.