Add the ability to manage entries added from other applications

[Fooughhy]

Is your feature request related to a problem? Please describe.
This is a great tool, as the hosts file can be a b**ch to organize! The issue I am having is that I use tools to add entries to the hosts file and (maybe I simply do not understand the tool) would like to somehow manage these entries easily. I use tools like Spybot Anti-Beacon which automatically add entries specifically to the default "hosts" file.

Describe the solution you'd like
Would like to somehow combine files into one hosts file. As stated, maybe I don't fully understand how it works. If I were to divide my hosts file into profiles, then use Anti-Beacon to update its entries, I would like to be able to add all of those new entries to the "Anti-Beacon" profile basically. If this is possible already, then disregard this.

Describe alternatives you've considered
What I've considered, as hostctl (to my knowledge) can target other hosts files easily, is to have several files for each tool and use hostctl to combine these into a "master" hosts file. This is cumbersome as it involves the swapping of hosts files (e.g if I have all Anti-Beacon entries in a 'hosts.beacon' file, when I want to update these entries I have to rename it to "hosts" and then use the tool to update the entries, rename it again to 'hosts.beacon' and use hostctl to import the new entries).

Additional context
The documentation for this tool seems (to me) inadequate as I am not entirely sure how to exactly import entries to the hosts file. I just now found how to add profiles, as the set command is not part of the "CLI Usage" documentation for some reason...

[guumaster]

@Fooughhy thanks for taking the time to add this issue.

AFAIK the OS uses only one hosts file. What hostctl can do is import data from other files into the main hosts file. If you want to manage data added from other tools you can just wrap the lines with the profile header/footer like this:

# profile some-other-tool
127.0.0.1 any.domain.loc
127.0.0.1 some.random.domain
# end

Then you can do all things hostctl allow with the profile some-other-tool as long as the header/footer are there.

If you have a hosts.beacon you can import it easily with hostctl add beacon --from hosts.beacon, and then disable or remove with hostctl remove beacon.

I'm not sure if I answered your question correctly. Is this info helpful?

I've updated the docs to change set to replace that is the proper command.

(Note: There is a --host-file parameter, but probably it's used mainly to test)

[Fooughhy]

Hi @guumaster ! Thanks for the reply!

What I meant was maybe more of an added functionality to hostctl, to be able to EASILY use and organize several hosts files. So that I can create a hosts.beacon file and have hostctl be able to incorporate that one into the regular one. Essentially use a pool of files, and run an "update" command for example to fetch the entries in these files. I could maybe assoiciate a profile with a file.

This still doesn't really make my original issue easier though, as what I now did was to remove the entries from the hosts file by using the original tool (Anti-Beacon) and reset hostctl. Then I added it through Anti-Beacon again, ran hostctl add antibeacon --from /etc/hosts (but for windows). This does not produce the intented results (for me) as there are now duplicates in the hosts file. So I remove the originals, disable the hostctl entries and add entries using another tool. This I have to do for each tool. That is the issue I am trying to find a solution to.

But I see your point that I can have another file 'hosts.beacon' which I add these entries from. But I still have to rename 'hosts.beacon' to 'hosts' to be able to manage the entries in that file (as the tool only uses the default 'hosts' file.

I know this is a very specific issue, I just wanted to describe it to see if there was a possibility for a solution, or if the functionality was already there but I just couldn't find it.

[guumaster]

Is the anti-beacon tool rewriting hosts file content?

Can you describe your ideal layout of files and ideal way of working of hostctl for your use case?

[smhmd]

to be able to EASILY use and organize several hosts files

@guumaster I think he's talking about #31, the ability to define a master profile from various profiles.

@Fooughhy, you conflict between describing your personal issue and your proposal. I think you should have used a far more minimal version of your personal issue to illustrate your feature request. And, perhaps, link to this anti-beacon tool. Could you focus on your proposal for a second (unless you don't have a concrete proposal)?

[Fooughhy]

@guumaster The anti-beacon tool is only adding entries, and it will recognize then even if I move them around.

@smhmd Yes, I know that my vision isn't clear and I didn't have that clear of a solution in mind when I wrote this.
Maybe I can split this up into several feature requests if I can be clear in my mind.

One problem, which maybe isn't the most important one, is that it would make the organization clearer if we were able to EASILY update the hosts file using the profiles. If the profiles contained (optionally) more information such as a file, or list of files, we may be able to simply use a command such as "update" to fetch new entries from these files when we add things to them. Everything in this tool is quite manual. This would make it more automatic.

Another problem is the organization of new entries. I have now updated my hosts file and divided everything into profiles. But when I use a tool, e.g Anti-Beacon, it will add new entries which are not in a profile. These new entries have to be manually added to a profile, while you still have to remove the old entries. There is a lot of duplicate work, atleast for me, using this tool.

I would maybe like a switch in the command to MOVE (or SET) the newly added entries (e.g entries in the 'default' profile) to a profile. Not to copy them.

And the Anti-Beacon tool can be found here.

[guumaster]

Thanks @Fooughhy for your patience. I get it better now.

Watching the hosts file is easy, but knowing to which profile copy new content is hard to infer.

Although, I think there is some changes that can be done to improve usage. We can add a cache of profiles for hostctl to store its content, this way the update feature you propose can be done.

Maybe if we have a layout like this:

$HOME/.hostctl/
 \_ profile_awesome
 \_ profile_x
 \_ ...

hostctl can use that folder as base for profile content. This will change how enable/disable works, but would result in a much cleaner hosts file. And also enable to undo remove actions.

All this will simplify some parts, but sitll not sure how to handle content added from other tools (like Anti-Beacon).

[Fooughhy]

I think it's you who has the patience while I figure out what I mean 👍
That is basically exactly what I mean. Even though it will introduce redundancy, it would make things clearer to work with.

What I want from the "added content from other tools" part is simply a parameter for the commands (such as ´hostctl add´) to MOVE content in a profile to another profile. Maybe this is the current functionality, but I did something wrong. There seems to be some special circumstances with the 'default' profile. I added the entries from this profile to another, then tried to remove the 'default' profile (this was my attempt at MOVING entries recently added to another profile). I do not recall if I tried to remove all entries in the 'default' profile or simply the profile itself, but this didn't work.

[guumaster]

Well, my view is that the default profile has to be always left alone. hostctl will only handle things added with hostctl and any previous content will remain untouched, except on backup/restore actions.

Also, moving from one profile to another adds lots of complexity and I think it won't be a much used feature.

I'm not discarding anything yet, but we need to come up with an elegant solution.

[smhmd]

@guumaster

Maybe if we have a layout like this:

$HOME/.hostctl/
 \_ profile_awesome
 \_ profile_x
 \_ ...

I think you should use $XDG_CACHE_HOME (typically $HOME/.cache/hostctl, to not further clutter $HOME.)

You've talked about a config file before. One thing that you could consider is an event-based config file where you can define commands to run on events (e.g. add, enable, disable --only, etc.) on specific profiles (e.g. awesome).

[Fooughhy]

@guumaster

Well, my view is that the default profile has to be always left alone. hostctl will only handle things added with hostctl and any previous content will remain untouched, except on backup/restore actions.

Also, moving from one profile to another adds lots of complexity and I think it won't be a much used feature.

I'm not discarding anything yet, but we need to come up with an elegant solution.

Yeah, that was my feeling regarding the 'default' profile and it makes perfect sense. Maybe my needs are simply out-of-scope for this tool.
But I'm still wondering why adding a MOVE command would add that much complexity?
Also, does this tools include some kind of regex functionality? Otherwise I could see that helping with the MOVE command, and in THAT case it could add alot of complexity.