WIP: Currently, this PR introduces globally applied mod_qosClient Level Control directives to establish rate limiting for our hg service. Although, the current configuration applies rate limiting specifically to hg.conf, it is set up to create a salt state that manages ratelimit.conf, installs mod_qospackage, uses symlinks to define and enable mod_qos, and loads configuration data from pillar.
To verify and test these changes locally,
bring up the salt-master, laptop:psf-salt user$ vagrant up salt-master
bring up the loadbalancer, laptop:psf-salt user$ vagrant up loadbalancer
bring up hg, laptop:psf-salt user$ vagrant up hg
in another window, ssh into the vagrant hg box, laptop:psf-salt user$ vagrant ssh hg
in the vagrant box, install curl sudo apt install curl
in the vagrant box, run the command for i in {1..10}; do curl -o /dev/null -s -w "%{http_code}\n" -k -H "Host: hg.python.org" https://127.0.0.1:9000/; done
Next steps to configure our loadbalancer as a privileged user to prevent it from getting rate limited.
This PR now includes a configuration which attempts to establsih our loadbalancer as a VIP user, however the loadbalancer is still getting rate limited where we would otherwise expect it to have no limit. To recreate this, follow the above steps and additionally include testing for our LB (below).
in the vagrant box, run the command for i in {1..10}; do curl -o /dev/null -s -w "%{http_code}\n" -k -H "Host: hg.python.org" https://192.168.50.19/; done
Included in this PR is a commented out block of code which attempts to use SrvMaxÇonnExcludeIP to achieve the same goal, but this also is not producing the expected outcome. Although, after reading over mod-qos docs I believe that this may be because this directive is considered a connection level control directive, whereas we are using client level control directives to establish rate limiting.
WIP: Currently, this PR introduces globally applied
mod_qosClient Level Control directives to establish rate limiting for our hg service. Although, the current configuration applies rate limiting specifically tohg.conf,it is set up to create a salt state that managesratelimit.conf, installsmod_qospackage, uses symlinks to define and enablemod_qos, and loads configuration data from pillar.To verify and test these changes locally,
laptop:psf-salt user$ vagrant up salt-masterlaptop:psf-salt user$ vagrant up loadbalancerlaptop:psf-salt user$ vagrant up hglaptop:psf-salt user$ vagrant ssh hgsudo apt install curlfor i in {1..10}; do curl -o /dev/null -s -w "%{http_code}\n" -k -H "Host: hg.python.org" https://127.0.0.1:9000/; doneNext steps to configure our loadbalancer as a privileged user to prevent it from getting rate limited.
This PR now includes a configuration which attempts to establsih our loadbalancer as a VIP user, however the loadbalancer is still getting rate limited where we would otherwise expect it to have no limit. To recreate this, follow the above steps and additionally include testing for our LB (below).
for i in {1..10}; do curl -o /dev/null -s -w "%{http_code}\n" -k -H "Host: hg.python.org" https://192.168.50.19/; doneIncluded in this PR is a commented out block of code which attempts to use
SrvMaxÇonnExcludeIPto achieve the same goal, but this also is not producing the expected outcome. Although, after reading overmod-qosdocs I believe that this may be because this directive is considered a connection level control directive, whereas we are using client level control directives to establish rate limiting.