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

fix(transparent-proxy): stop logging all to stderr when installing tproxy #10045

Conversation

bartsmykla
Copy link
Contributor

@bartsmykla bartsmykla commented Apr 23, 2024

Because of the construction of the log line, where everything was located at the same line, we were not able to figure out at the beginnig of the log if it'll be successfull or not, so everything was logged in stderr. It's wrong when you have a monitoring set to watch stderr. I changed it so now the same information is placed in multiple lines and only failure is send to stderr.

Examples:

# kumactl is about to apply the iptables rules that will enable transparent proxying on the machine. The SSH connection may drop. If that happens, just reconnect again.
# [1/5] writing following contents to rules file: /tmp/iptables-rules-1713857949369149426.txt3315697516
* nat
-N KUMA_MESH_INBOUND
-N KUMA_MESH_OUTBOUND
-N KUMA_MESH_INBOUND_REDIRECT
-N KUMA_MESH_OUTBOUND_REDIRECT
-A PREROUTING -p tcp -j KUMA_MESH_INBOUND
-A OUTPUT -p tcp -j KUMA_MESH_OUTBOUND
-A KUMA_MESH_INBOUND -p tcp -j KUMA_MESH_INBOUND_REDIRECT
-A KUMA_MESH_OUTBOUND -s 127.0.0.6/32 -o lo -j RETURN
-A KUMA_MESH_OUTBOUND -p tcp -o lo ! -d 127.0.0.1/32 -m owner --uid-owner 5678 -j KUMA_MESH_INBOUND_REDIRECT
-A KUMA_MESH_OUTBOUND -p tcp -o lo -m owner ! --uid-owner 5678 -j RETURN
-A KUMA_MESH_OUTBOUND -m owner --uid-owner 5678 -j RETURN
-A KUMA_MESH_OUTBOUND -d 127.0.0.1/32 -j RETURN
-A KUMA_MESH_OUTBOUND -j KUMA_MESH_OUTBOUND_REDIRECT
-A KUMA_MESH_INBOUND_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A KUMA_MESH_OUTBOUND_REDIRECT -p tcp -j REDIRECT --to-ports 15001
COMMIT
# [1/5] /usr/sbin/iptables-nft-restore -n /tmp/iptables-rules-1713857949369149426.txt3315697516
# iptables set to diverge the traffic to Envoy
# Transparent proxy set up successfully, you can now run kuma-dp using transparent-proxy.
# kumactl is about to apply the iptables rules that will enable transparent proxying on the machine. The SSH connection may drop. If that happens, just reconnect again.
# [1/5] writing following contents to rules file: /tmp/iptables-rules-1713857756759164748.txt2242814141
* nat
-N KUMA_MESH_INBOUND
-N KUMA_MESH_OUTBOUND
-N KUMA_MESH_INBOUND_REDIRECT
-N KUMA_MESH_OUTBOUND_REDIRECT
-A PREROUTING -p tcp -j KUMA_MESH_INBOUND
-A OUTPUT -p tcp -j KUMA_MESH_OUTBOUND
-A KUMA_MESH_INBOUND -p tcp -j KUMA_MESH_INBOUND_REDIRECT
-A KUMA_MESH_OUTBOUND -s 127.0.0.6/32 -o lo -j RETURN
-A KUMA_MESH_OUTBOUND -p tcp -o lo ! -d 127.0.0.1/32 -m owner --uid-owner 5678 -j KUMA_MESH_INBOUND_REDIRECT
-A KUMA_MESH_OUTBOUND -p tcp -o lo -m owner ! --uid-owner 5678 -j RETURN
-A KUMA_MESH_OUTBOUND -m owner --uid-owner 5678 -j RETURN
-A KUMA_MESH_OUTBOUND -d 127.0.0.1/32 -j RETURN
-A KUMA_MESH_OUTBOUND -j KUMA_MESH_OUTBOUND_REDIRECT
-A KUMA_MESH_INBOUND_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A KUMA_MESH_OUTBOUND_REDIRECT -p tcp -j REDIRECT --to-ports 15001
COMMIT
# [1/5] /usr/sbin/iptables-nft-restore -n /tmp/iptables-rules-1713857756759164748.txt2242814141
# [1/5] failed with error: 'iptables-nft-restore: line 2 failed: Chain already exists.: exit status 1'
# [1/5] trying fallback
# [1/5] writing following contents to rules file: /tmp/iptables-rules-1713857756759164748.txt2242814141
* nat
-N KUMA_MESH_INBOUND
-N KUMA_MESH_OUTBOUND
-N KUMA_MESH_INBOUND_REDIRECT
-N KUMA_MESH_OUTBOUND_REDIRECT
-A PREROUTING -p tcp -j KUMA_MESH_INBOUND
-A OUTPUT -p tcp -j KUMA_MESH_OUTBOUND
-A KUMA_MESH_INBOUND -p tcp -j KUMA_MESH_INBOUND_REDIRECT
-A KUMA_MESH_OUTBOUND -s 127.0.0.6/32 -o lo -j RETURN
-A KUMA_MESH_OUTBOUND -p tcp -o lo ! -d 127.0.0.1/32 -m owner --uid-owner 5678 -j KUMA_MESH_INBOUND_REDIRECT
-A KUMA_MESH_OUTBOUND -p tcp -o lo -m owner ! --uid-owner 5678 -j RETURN
-A KUMA_MESH_OUTBOUND -m owner --uid-owner 5678 -j RETURN
-A KUMA_MESH_OUTBOUND -d 127.0.0.1/32 -j RETURN
-A KUMA_MESH_OUTBOUND -j KUMA_MESH_OUTBOUND_REDIRECT
-A KUMA_MESH_INBOUND_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A KUMA_MESH_OUTBOUND_REDIRECT -p tcp -j REDIRECT --to-ports 15001
COMMIT
# [1/5] /usr/sbin/iptables-legacy-restore --wait=5 -n /tmp/iptables-rules-1713857756759164748.txt2242814141
# [1/5] failed with error: 'iptables-restore: line 2 failed: exit status 1'
# [1/5] will try again in 2s
...

Checklist prior to review

  • Link to relevant issue as well as docs and UI issues
    • No relevant issues
  • This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as a image registry) and it will work on Windows, system specific functions like syscall.Mkfifo have equivalent implementation on the other OS
    • It won't
  • Tests (Unit test, E2E tests, manual test on universal and k8s)
    • Manually tested locally
    • Don't forget ci/ labels to run additional/fewer tests
  • Do you need to update UPGRADE.md?
    • There is no need
  • Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label) --

Because of the construction of the log line, where everything was
located at the same line, we were not able to figure out at the
beginnig of the log if it'll be successfull or not, so everything
was logged in stderr. It's wrong when you have a monitoring set
to watch stderr. I changed it so now the same information is
placed in multiple lines and only failure is send to stderr.

Signed-off-by: Bart Smykla <bartek@smykla.com>
@bartsmykla bartsmykla requested a review from slonka April 23, 2024 07:54
@bartsmykla bartsmykla requested a review from a team as a code owner April 23, 2024 07:54
@bartsmykla bartsmykla requested review from jijiechen and lukidzi and removed request for a team April 23, 2024 07:54
Co-authored-by: Mike Beaumont <mjboamail@gmail.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
@bartsmykla bartsmykla enabled auto-merge (squash) April 23, 2024 11:18
@bartsmykla bartsmykla merged commit de0f8b5 into kumahq:master Apr 23, 2024
15 checks passed
Copy link
Contributor

github-actions bot commented Apr 23, 2024

backporting to release-2.7 with action

backporting to release-2.6 with action
backporting to release-2.3 with action
backporting to release-2.5 with action
backporting to release-2.4 with action

kumahq bot pushed a commit that referenced this pull request Apr 23, 2024
…roxy (#10045)

Because of the construction of the log line, where everything was
located at the same line, we were not able to figure out at the
beginnig of the log if it'll be successfull or not, so everything
was logged in stderr. It's wrong when you have a monitoring set
to watch stderr. I changed it so now the same information is
placed in multiple lines and only failure is send to stderr.

Signed-off-by: Bart Smykla <bartek@smykla.com>
kumahq bot pushed a commit that referenced this pull request Apr 23, 2024
…roxy (#10045)

Because of the construction of the log line, where everything was
located at the same line, we were not able to figure out at the
beginnig of the log if it'll be successfull or not, so everything
was logged in stderr. It's wrong when you have a monitoring set
to watch stderr. I changed it so now the same information is
placed in multiple lines and only failure is send to stderr.

Signed-off-by: Bart Smykla <bartek@smykla.com>
kumahq bot pushed a commit that referenced this pull request Apr 23, 2024
…roxy (#10045)

Because of the construction of the log line, where everything was
located at the same line, we were not able to figure out at the
beginnig of the log if it'll be successfull or not, so everything
was logged in stderr. It's wrong when you have a monitoring set
to watch stderr. I changed it so now the same information is
placed in multiple lines and only failure is send to stderr.

Signed-off-by: Bart Smykla <bartek@smykla.com>
kumahq bot pushed a commit that referenced this pull request Apr 23, 2024
…roxy (#10045)

Because of the construction of the log line, where everything was
located at the same line, we were not able to figure out at the
beginnig of the log if it'll be successfull or not, so everything
was logged in stderr. It's wrong when you have a monitoring set
to watch stderr. I changed it so now the same information is
placed in multiple lines and only failure is send to stderr.

Signed-off-by: Bart Smykla <bartek@smykla.com>
kumahq bot pushed a commit that referenced this pull request Apr 23, 2024
…roxy (#10045)

Because of the construction of the log line, where everything was
located at the same line, we were not able to figure out at the
beginnig of the log if it'll be successfull or not, so everything
was logged in stderr. It's wrong when you have a monitoring set
to watch stderr. I changed it so now the same information is
placed in multiple lines and only failure is send to stderr.

Signed-off-by: Bart Smykla <bartek@smykla.com>
bartsmykla added a commit that referenced this pull request Apr 23, 2024
…roxy (backport of #10045) (#10047)

fix(transparent-proxy): stop logging all to stderr when installing tproxy (#10045)

Because of the construction of the log line, where everything was
located at the same line, we were not able to figure out at the
beginnig of the log if it'll be successfull or not, so everything
was logged in stderr. It's wrong when you have a monitoring set
to watch stderr. I changed it so now the same information is
placed in multiple lines and only failure is send to stderr.

Signed-off-by: Bart Smykla <bartek@smykla.com>
Co-authored-by: Bart Smykla <bartek@smykla.com>
bartsmykla added a commit that referenced this pull request Apr 23, 2024
…roxy (backport of #10045) (#10048)

fix(transparent-proxy): stop logging all to stderr when installing tproxy (#10045)

Because of the construction of the log line, where everything was
located at the same line, we were not able to figure out at the
beginnig of the log if it'll be successfull or not, so everything
was logged in stderr. It's wrong when you have a monitoring set
to watch stderr. I changed it so now the same information is
placed in multiple lines and only failure is send to stderr.

Signed-off-by: Bart Smykla <bartek@smykla.com>
Co-authored-by: Bart Smykla <bartek@smykla.com>
bartsmykla added a commit that referenced this pull request Apr 23, 2024
…roxy (backport of #10045) (#10050)

* fix(transparent-proxy): stop logging all to stderr when installing tproxy (#10045)

Because of the construction of the log line, where everything was
located at the same line, we were not able to figure out at the
beginnig of the log if it'll be successfull or not, so everything
was logged in stderr. It's wrong when you have a monitoring set
to watch stderr. I changed it so now the same information is
placed in multiple lines and only failure is send to stderr.

Signed-off-by: Bart Smykla <bartek@smykla.com>
Co-authored-by: Bart Smykla <bartek@smykla.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants