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

Allow multiple CLI bindings #239

Open
wonko opened this issue May 9, 2023 · 0 comments
Open

Allow multiple CLI bindings #239

wonko opened this issue May 9, 2023 · 0 comments
Labels
Feature Request Enhancement to existing functionality or new functionality

Comments

@wonko
Copy link

wonko commented May 9, 2023

:person_frowning: Problem Statement

In certain cases, it's needed to supply multiple CLI binding addresses/ports. One example is when a private network is being used to connect the caching layer to webservices. The webservice layer needs to be able to set bans (or ...), while it might also be needed to still connect from localhost.

❔ Possible Solution

Currently, the address and the port are single entries, separated. It suggest to make this a single item (host and port), but to allow an array.

varnish_config 'default' do 
 ...
 admin_listen_bindings ['127.0.0.1:6082', '192.168.0.1:60820']
...
end

This would then be translated towards the correct startup parameters as varnishd allows to add multiple CLI bindings:

root@web-003:~# varnishd -? | grep -A1 -- -T 
varnishd: invalid option -- '?'
  -T address[:port]            # CLI address
                               # Can be specified multiple times.

See https://github.com/sous-chefs/varnish/blob/main/templates/default_systemd.erb#L31

The old parameters can be added to the array as the only option, if no bindings are supplied.

⤴️ Describe alternatives you've considered

No way of doing this decently without seriously dirty fiddling (adding a value for port with a portnumber, a space, a -T followed with a second binding ... but I'd consider this as being a dirty hack).

Another alternative is to bind to '*' and then to add firewalling rules to block this. However, I find this bad practice, and it takes away the possibility to allow multiple ports to be used.

@wonko wonko added the Feature Request Enhancement to existing functionality or new functionality label May 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Enhancement to existing functionality or new functionality
Projects
None yet
Development

No branches or pull requests

1 participant