I’m proud to share a major development status update of XPipe, a new connection hub that allows you to access your entire server infrastructure from your local desktop. It works on top of your installed command-line programs and does not require any setup on your remote systems. So if you normally use CLI tools like ssh, docker, kubectl, etc. to connect to your servers, it will automatically integrate with them.
Here is how it looks like if you haven’t seen it before:
Local forwarding for services
Many systems run a variety of different services such as web services and others. There is now support to detect, forward, and open the services. For example, if you are running a web service on a remote container, you can automatically forward the service port via SSH tunnels, allowing you to access these services from your local machine, e.g., in a web browser. These service tunnels can be toggled at any time. The port forwarding supports specifying a custom local target port and also works for connections with multiple intermediate systems through chained tunnels. For containers, services are automatically detected via their exposed mapped ports. For other systems, you can manually add services via their port.
Markdown notes
Another feature commonly requested was the ability to create and share notes for connections. As Markdown is everywhere nowadays, it makes sense so to implement any kind of note-taking functionality with Markdown. So you can now add notes to any connection with Markdown. The full spec is supported. The editing is delegated to a local editor of your choice, so you can have access to advanced editing features and syntax highlighting there.
Proxmox improvements
You can now automatically open the Proxmox dashboard website through the new service integration. This will also work with the service tunneling feature for remote servers.
You can now open VNC sessions to Proxmox VMs.
The Proxmox support has been reworked to support one non-enterprise PVE node in the community edition.
Scripting improvements
The scripting system has been reworked. There have been several issues with it being clunky and not fun to use. The new system allows you to assign each script one of multiple execution types. Based on these execution types, you can make scripts active or inactive with a toggle. If they are active, the scripts will apply in the selected use cases. There currently are these types:
- Init scripts: When enabled, they will automatically run on init in all compatible shells. This is useful for setting things like aliases consistently
- Shell scripts: When enabled, they will be copied over to the target system and put into the PATH. You can then call them in a normal shell session by their name, e.g.
myscript.sh, also with arguments. - File scripts: When enabled, you can call them in the file browser with the selected files as arguments. Useful to perform common actions with files
Native window styles
The application styling has been improved to fit in better with native window decorations:
A new HTTP API
For a programmatic approach to manage connections, XPipe 10 comes with a built-in HTTP server that can handle all kinds of local API requests. There is an openapi.yml spec file that contains all API definitions and code samples to send the requests.
To start off, you can query connections based on various filters. With the matched connections, you can start remote shell sessions and for each one and run arbitrary commands in them. You get the command exit code and output as a response, allowing you to adapt your control flow based on command outputs. Any kind of passwords and other secrets are automatically provided by XPipe when establishing a shell connection. You can also access the file systems via these shell connections to read and write remote files.
A note on the open-source model
Since it has come up a few times, in addition to the note in the git repository, I would like to clarify that XPipe is not fully FOSS software. The core that you can find on GitHub is Apache 2.0 licensed, but the distribution you download ships with closed-source extensions. There’s also a licensing system in place as I am trying to make a living out of this. I understand that this is a deal-breaker for some, so I wanted to give a heads-up.
The system is designed to allow for unlimited usage in non-commercial environments and only requires a license for more enterprise-level environments. This system is never going to be perfect as there is not a very clear separation in what kind of systems are used in, for example, homelabs and enterprises. But I try my best to give users as many free features as possible for their personal environments.
Outlook
If this project sounds interesting to you, you can check it out on GitHub! There are more features to come in the near future.
Enjoy!
Looks really nice definitely gonna take a look at it.
And, did I read that correctly: the pro licence is a onetime payment and you keep the all the current features even after the licence expires?
Yes
I’ve been using this for a few months now. Its really great.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters HTTP Hypertext Transfer Protocol, the Web SCP Secure Copy encrypted file transfer tool, authenticates and transfers over SSH SSH Secure Shell for remote terminal access SSO Single Sign-On
3 acronyms in this thread; the most compressed thread commented on today has 4 acronyms.
[Thread #901 for this sub, first seen 1st Aug 2024, 20:35] [FAQ] [Full list] [Contact] [Source code]
Xpipe has rapidly become an essential part of my day to day workflow. I wish I could get it to play nice with MobaXTerm as I prefer that to any of the supported terminals, but that’s really my only gripe. In every other regard it’s just an excellent toolkit for managing remote devices.
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.
I’ve seen multiple markdown standards; which one did you implement?
It should be close to the CommonMark spec, so it should support the same features as you find e.g. in GitHub markdown.
This seems really cool and might be very helpful to me, but I don’t want to install it on my computer. I don’t see a docker image for it, though it seems like it would be easy to create one; but this is a GUI app, so how would I run it in a container somewhere and use it via the GUI on my local computer? Or if I install it in its own VM (I use Proxmox), I’d have to use a remote desktop app like vlc or something, right?
I’m a noob at this so there’s tons I just don’t know.
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.
I host a bunch of containers on a few servers, but I don’t do any of it from my local computer. I have a VM (Debian) that I ssh into and do everything from there. Shouldn’t XPipe work the same on that VM as it would on my local computer? I wouldn’t think XPipe would care (or know) if it was running on a VM, as long as that VM has a shell it can integrate with.
But I suppose even if that’s true and XPipe works fine in the VM, there is still the issue of displaying the GUI on my local computer.
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.
Thanks for the help and suggestions!
It turns out that my template Debian VM doesn’t have a DE in it, and that’s why I couldn’t forward the GUI from the VM to my local machine: there was not GUI. I installed XFCE on the VM and now I can run XPipe on the VM from my local computer, without XPipe being installed on my local computer:
ssh -X user@vm_ip_address xpipe openI look forward to playing with XPipe - it looks cool and very helpful!
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.
Looks really cool. I’ve been working on implementing SSO through Authentik for every home lab service that supports it (Like Proxmox!) Do you think you’ll add SSO/SAML? If you do, I recommend not locking it behind the enterprise plan to encourage adoption.
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.
I’ve seen this project just get better and better. Thes improvements are awesome. The tool gives you so many ways to do things, it’s amazing. I covered it on my channel a while back, and someone who watched reported a bug and it was fixed within a couple of days. Try that with any of the big tech giants. You all rock! Well done!
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.
