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 [email protected], 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.
Yeah the commercialization model is not perfect yet. Ideally the community edition should include all normal features required for personal use. Would that only be like one machine to connect to or many? I was planning to experiment with allowing a few connections where a license would be required in the community version.
It uses the sudo credentials from the SSH connection, even if you don’t need to provide a password to login. So if you set a password for a SSH connection, it should use that for the sudo elevation.
You can send me feature requests either on GitHub, Discord, or mail, whatever you like.
Your proposed enhancements make sense, I can already think about how to add this the best way. And if you want to open a proper feature request and elaborate more on that, we can make that happen for sure.
As a sole developer I have to prioritize features due to the time constraints. While I would definitely like to implement support for everything you listed, this would be a lot of work. For example with terminals in general, it can be very difficult to get one up to the standards of other comparable terminals. By delegating everything to other terminals, I can make the development easier.
So in the long term future this might be added. But that also depends on the project’s trajectory going forward
Yeah I can understand why some people feel that way. Originally this closed part only concerned a very small part, but due to necessary subclassing of that implementation, that kinda evolved to the whole shell handling interface. I always wanted to refactor that aspect and decouple it such that these parts can be included in this repository, but never got around to it.
Maybe in the future this can be properly addressed because it’s more a matter of a not well thought out structure rather than hiding crazy secret implementation details. The whole project’s vision moved around quite a lot and most stuff was conceptioned before there was even a thought to try to sell it.
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.