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 request: Host list via file with update on every request #6

Open
ixpict opened this issue Jun 21, 2023 · 4 comments
Open

Feature request: Host list via file with update on every request #6

ixpict opened this issue Jun 21, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@ixpict
Copy link
Contributor

ixpict commented Jun 21, 2023

Using arguments via cli severely limits the launch of such a proxy by the local computer. For a small team a variant with a file of hosts or even better some kind of database would be perfect.

@ixpict ixpict changed the title Feature request: Host list file via file with update on every request Feature request: Host list via file with update on every request Jun 21, 2023
@jay7x
Copy link
Owner

jay7x commented Jun 21, 2023

I see the point and I thought about having a config file too.. Though I've considered 2 ways for future:

  1. To have a etc-hosts-proxy hosts update -H example.com=1.2.3.4 [ -H ... ] which just updates a yaml/json config file.
  2. To have a REST API on some predefined fake hostname (privoxy has it on http://p.p e.g.) which allows to modify host mapping (and maybe to save the state in a json file)

As expected, this leads to another question.. how to reload the config? My ideas were:

  1. etc-hosts-proxy reload.. i.e. no auto-reload, just kick the proxy manually.
  2. To setup some kind of inotify()-like watcher thread which reloads the config on a file change.

Now you've proposed 3rd way which might be easier than (2).. maybe I can accept the idea of doing stat() on a config file per request.. it's just personal small proxy in the end, not a telecom-grade solution :)

@jay7x jay7x added the enhancement New feature or request label Jun 21, 2023
@ixpict
Copy link
Contributor Author

ixpict commented Jul 2, 2023

I think first way is better with some api for reload and check updates via SIGHUP as the second way. inotify - is not very useful in containters and you need to extend inotify limits in some environments.

@jay7x
Copy link
Owner

jay7x commented Jul 2, 2023

Thank you for explaining the inotify() limits, I didn't thought about containers again.. My main concern was OS support here.

Ok, that sounds reasonable.. Let's keep this open for a while. My long weekend is over so I should find some time to work on this later.

@ixpict
Copy link
Contributor Author

ixpict commented Jul 2, 2023

We live in the 21st century and containers are the most versatile package managers right now :) nobody wants to overthink things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants