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

[bug] GUAC issues with ipv6 running docker compose on Colima #888

Open
mlieberman85 opened this issue May 25, 2023 · 5 comments
Open

[bug] GUAC issues with ipv6 running docker compose on Colima #888

mlieberman85 opened this issue May 25, 2023 · 5 comments
Labels
bug Something isn't working

Comments

@mlieberman85
Copy link
Collaborator

Describe the bug
I am opening this up here instead of the docs or visualizer repos since this issue probably could affect multiple areas of GUAC.

Running the demos via Lima/Colima for running docker compose will fail with ipv6 issues.

GUAC Visualizer will giver errors like: Failed to proxy http://localhost:8080/query Error: connect ECONNREFUSED ::1:8080

Node will no longer resolve ipv4 unless explicitly told to.

See: abiosoft/colima#583

The issue is related to:

To Reproduce
Steps to reproduce the behavior:

Run demos when using docker compose with colima running instead of docker desktop.

@mlieberman85 mlieberman85 added the bug Something isn't working label May 25, 2023
@mlieberman85 mlieberman85 changed the title [bug] GUAC issues with [bug] GUAC issues with ipv6 running docker compose on Colima May 25, 2023
@arorasoham9
Copy link
Contributor

I would like to help with this issue.

@pxp928
Copy link
Collaborator

pxp928 commented Jul 25, 2023

hmm @mlieberman85 is this still an issue with the new guac visualizer?

@mlieberman85
Copy link
Collaborator Author

I will need to check after all the updates to the docker compose.

@lumjjb
Copy link
Contributor

lumjjb commented Aug 21, 2023

@mlieberman85 were you able to check if this was resolved?

@mlieberman85
Copy link
Collaborator Author

This still affects the visualizer by default but the env var does allow for folks to fix it themselves. Do we want to make the default address 127.0.0.1 in the next.config.js which should probably support all the common use cases with no action on the user end?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants