Closed pascal-zarrad closed 1 year ago
we should just enforce the output format we expect, however, this issue will be across all bouncer repos as the same script is deployed across all of them. Assigned mmetc to have visibility.
Done, and thanks for reporting!
Although I wouldn't recommend a global setting for the cscli output, it's too easy to break scripts by accident.
I just stumbled upon some really weird bug regarding the installation of this bouncer while writing an Ansible role. The installation fails when
cscli.output
is configured and set tojson
for the CrowdSec engine before the bouncer is installed.If this issue is approved, I'd implement the solution mentioned below and open a PR.
Reproduce
config.yaml.local
or edit the existingconfig.yaml
and setcscli.output
tojson
crowdsec-firewall-bouncer-iptables
using aptExpected
Installation of the bouncer completes as expected and the bouncer is started.
The
api_url
for the bouncer is configured like this:Actual
The bouncer uses the
cscli
to get the address for the local API.For the formats, the output looks like this:
127.0.0.1:8080
127.0.0.1:8080
"127.0.0.1:8080"
The quotation marks in the JSON output cause the value in the generated
crowdsec-firewall-bouncer.yaml
to look like this:Solution
Firstly, the workaround is to just stick to
human
orraw
forcscli.output
to ensure the installation works as expected.The long term solution would be to enforce raw output on the commands in
_bouncer.sh
, like it is already used in this line. This is for thebouncers add
command, however the--output
option is also available forconfig show
.Example with
cscli.output: json
inconfig.yaml
:The
-oraw
should be added to the following two lines to ensure JSON doesn't break:I choose
raw
instead ofhuman
as I think it matches the use case here best.System Info
OS: Debian 12 Source: APT