-
Notifications
You must be signed in to change notification settings - Fork 220
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
cmd/create, doc/toolbox-create, sh: Add flag --hostname to create command. #573
Conversation
You shouldn't ssh from the toolbox? This (might) break some workflows that depend on the hostname being set to toolbox for the detection of a toolbox environment |
#563 seems like a better solution imo |
To clarify, I am not ssh from within the toolbox. I ssh from a remote host to my host machine with X forwarding, then run |
…mand. When SSH to a host, ~/.Xauthority will be used for xauth; the entries in it contains the hostname. If within the toolbox container it uses another hostname, the xauth will fail. Therefore we need to be able to specify the hostname when creating the container. containers#573
…mand. When SSH to a host, ~/.Xauthority will be used for xauth; the entries in it contains the hostname. If within the toolbox container it uses another hostname, the xauth will fail. Therefore we need to be able to specify the hostname when creating the container. containers#573
Addressed comments. Please take another look. Thanks. |
Build failed.
|
…mand. When SSH to a host, ~/.Xauthority will be used for xauth; the entries in it contains the hostname. If within the toolbox container it uses another hostname, the xauth will fail. Therefore we need to be able to specify the hostname when creating the container. containers#573
…mand. When SSH to a host, ~/.Xauthority will be used for xauth; the entries in it contains the hostname. If within the toolbox container it uses another hostname, the xauth will fail. Therefore we need to be able to specify the hostname when creating the container. containers#573
…mand. When SSH to a host, ~/.Xauthority will be used for xauth; the entries in it contains the hostname. If within the toolbox container it uses another hostname, the xauth will fail. Therefore we need to be able to specify the hostname when creating the container. containers#573
Build failed.
|
…mand. When SSH to a host, ~/.Xauthority will be used for xauth; the entries in it contains the hostname. If within the toolbox container it uses another hostname, the xauth will fail. Therefore we need to be able to specify the hostname when creating the container. containers#573
Build failed.
|
…mand. When SSH to a host, ~/.Xauthority will be used for xauth; the entries in it contains the hostname. If within the toolbox container it uses another hostname, the xauth will fail. Therefore we need to be able to specify the hostname when creating the container. containers#573
Addressed comments and resolved conflicts. It is ready for review, please take a look, thanks. |
…mand. When SSH to a host, ~/.Xauthority will be used for xauth; the entries in it contains the hostname. If within the toolbox container it uses another hostname, the xauth will fail. Therefore we need to be able to specify the hostname when creating the container. containers#573
Build succeeded.
|
This implementation is better than the one I've been trying to put together. I like that this mimics the It would be awesome to see this approved and merged as having a dozen or so toolboxes that all have the prompt |
This looks completely reasonable and I'd very much like to see this land. I am in the same situation as absenth above: I have multiple toolboxes for different projects/distros and I'd really like to be able to name them sanely and easily. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes look completely sane to me.
The recommended way to detect a Toolbx environment is to look for the |
Given the timing, I am tempted to ask if you have seen this commit and whether it improves your situation? Does the suggestion in #969 to include the host's hostname as a suffix in the container's hostname (eg., toolbox. or something similar) help? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -390,7 +396,7 @@ func createContainer(container, image, release string, showCommandToEnter bool) | |||
createArgs = append(createArgs, xdgRuntimeDirEnv...) | |||
|
|||
createArgs = append(createArgs, []string{ | |||
"--hostname", "toolbox", | |||
"--hostname", createFlags.hostname, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't directly use createFlags.hostname
in createContainer
because src/cmd/run.go
also uses this function.
There are at least two different immediate problems here. First, there's a need to come up with a better default hostname for the Toolbx containers. See #969, and all the issues and pull requests linked from it, for the discussion. This is often conflated with a desire to make it easier to distinguish one container from another, because the hostname shows up in some very vsible places. eg., in the shell's prompt, the terminal emulator's window chrome, etc.. However, they aren't exactly the same. However, they aren't exactly the same thing. It's already possible today to use This will probably satisfy a big chunk of users out there. Then, there's the question of letting users customize the hostname, which is what #563 is about, but it has some problems that need to be figured out. |
I am going to have to close this pull request. However, you are welcome to help implement #969 Either way, thanks for your interest in Toolbx and contributing to the discussion! |
I am still interested in solving your problem with SSH and X forwarding. I am currently inside a Wayland session, which makes it difficult for me to reproduce your problem. So, feel free to open a new issue with the above details to further investigate it. |
When SSH to a host, ~/.Xauthority will be used for xauth; the entries in it contains the hostname. If within the toolbox container it uses another hostname, the xauth will fail. Therefore we need to be able to specify the hostname when creating the container.