In terms of any authentication, XPipe doesn’t implement anything by itself. It will just delegates to your local SSH client. If you can set that up with your ssh client so that you can successfully connect from the command line, it should also work in XPipe.
Alright I guess that approach works.
But installing it locally should be much easier. It can also access connections through your VM via ssh from there.
It should also work in a graphical VM, but I assume that you have your tools installed on your desktop. E.g. your preferred terminal or editor since you only have a console in your VM via ssh.
If you install XPipe on your desktop, it can connect to the VM from there and through the VM also connect to all your other servers as a gateway.
It’s intended to be installed on your local desktop because it integrates with your installed programs like your system shell, text editor, terminal, etc. This would not be possible if it would be installed in a container or VM. I can understand some concerns about installing software on you local machine, but this is a case where creating an isolated container for an application would not make sense.
That is great to hear!
Alright, I will have to look into whether it is possible to differentiate between normal and FIPS here
How large is your homelab cluster? The current restriction of only one Proxmox node is mainly there because in practice I don’t think it would be possible to distinguish between personal use and commercial use. Because many companies also run a cluster with multiple nodes without the enterprise repository as that is not really needed.
The display issue is interesting because I was not aware of that before. I have a few Linux systems with a gnome DE, but none of these are using nvidia hardware acceleration. I can definitely look into finding the cause for this if you want, but it’s only really worth it for you to spend some time on this if you actually want to keep using XPipe. If the current restrictions are a dealbreaker for you, then I understand that.
I think a screenshot of how exactly it looks for you would already be a good starting point for me.
I guess that depends on what you consider basic homelab functions. As I mentioned, I know that that any commercialization model is not going to be perfect but I try to allow for as much free usage as reasonably possible.
About the text scaling, I will have to look into that. I know that some desktop environments are weird with their display scaling and that it is not getting rendered properly there.
That is great to hear!
For MobaXTerm you can always try to ask the devs to maybe expose the functionality to launch their terminal from the command-line. That would work.
Do you use the normal one or the FIPS one? Maybe I can use that to differentiate between personal and commercial use
Alright I see. With the more professional homelab setups it will be always difficult to properly differentiate all cases for the community and professional edition here.
But you can send me an email at crschnick@xpipe.io, I can provide you with an evaluation license.
It should be close to the CommonMark spec, so it should support the same features as you find e.g. in GitHub markdown.
I assumed that yubikeys would be found pretty much only in enterprise environments but perhaps I was wrong there.
Maybe I can find a solution to that. The free plan restrictions are not perfect yet and I was planning to experiment with different solutions to it. If you just want to try it out, I can also offer evaluation licenses if you’re interested.
You can if you’re interested in any status updates
Yeah I can do that
Yeah I did not downvote you, feel free to take a dive into the data if you really care about that.
I think your analogy about the cars can be augmented a bit. I would say that individual components like VNC are not really a car to begin with. VNC is an insecure protocol by default. Technically there are VNC security measures to potentially encode the data, but these are often not used*. Furthermore, even if you encrypt the data stream, VNC authentication options are severely limited. So something like VNC needs to run over something like a SSH tunnel to be considered properly secure. And to properly do that, you need an SSH integration as well. That is one example where these synergies happen in XPipe.
And not to only aggregate them in one view but to also make them interact with each other. It’s not just about having SSH connections, docker containers, or VNC connections side by side, but using them together. For example, any VNC connection in XPipe is automatically tunneled over SSH, so you don’t even need to expose the port. If you add a system in XPipe via SSH, you will automatically have access to a VNC connection as well if a VNC server is running on it. Doing all of that manually is definitely possible, but will take you some time to set up and start each time.
It is a frontend for standard CLI tools yes, but it comes with many additional features. The focus is especially on integrating standard CLI tools with your desktop environment and other applications that you use like editors or terminals.
For example, of course you can just use the ssh CLI to connect to your server and edit files. But with XPipe you can do the same thing but more comfortably. You can source passwords from your local password manager CLI, automatically launch terminals with the SSH session, edit remote files with your locally installed text editor, and more.
Of course you can do this also with tools like putty, but the difference here is the integration. Other tools ship their own SSH client with its own capabilities, features, and limitations. They also have their own terminal. XPipe preserves full compatibility with your local SSH client and terminal. E.g. all your configuration options are properly applied, your configs are automatically sourced, any advanced authentication features like gpg keys, smartcards, etc. work out of the box.
The same approach is also used for the integrations for docker, podman, LXD, and more, so you can use it for a large variety of use cases.
Thanks for your video showcase back then, it really helped the project get the initial traction.
The project was definitely rough around the edges back then. It held together somewhat but I would say it was around a 50/50 chance that it would work as expected for a new user. I think that has been the biggest improvement since then, the reliability and handling of edge cases so that the vast majority of users can now use it as they expect without issues. That was made possible with the help of the community which reported and tested all kinds of things I could not have done on my own. Having a community running a diverse set of systems helps out development immensely.