I’m proud to share a development status update of XPipe, a shell connection hub and remote file manager that allows you to access your entire server infrastructure from your local machine. 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, you can just use XPipe on top of that.

Here is how it looks like if you haven’t seen it before:

Connections

Browser

Since the last status update some months ago, a lot of things have changed thanks to the community sharing a lot of feedback and reporting issues. Overall, the project is now in a much more stable state as all the accumulated issues have been fixed. Furthermore, many feature requests have been implemented.

XPipe 8 is this biggest update yet and includes many new features and changes that are necessary going forward to allow for future features to come. The versioning scheme has also been changed to simplify version numbers. So we are going straight from 1.7 to 8.0.

New terminal launcher

The terminal launcher functionality got completely reworked with the goal to make it more flexible and improve the terminal startup performance. You will quickly notice the new implementation whenever you launch any connection in your terminal. The new implementation allows us to start up a connection while the terminal is still opening, shaving off a lot of time.

File browser improvements

The file browser has been reworked in terms of performance and reliability. File transfers of many files are now faster, and any errors that can occur are now handled better.

In terms of the interface, there is also now a progress indicator for files being transferred. For any file conflicts, there is now a new dialog to choose how to resolve any conflict when copying or moving files.

Authentication improvements

This update comes with a newly created system for handling authentication that is better suited for arbitrary authentication prompts. This allows for better support for things like 2FA and other keyboard interactive authentications schemes. The sudo elevation authentication also has been reworked to be more intuitive and mirror the behavior of the system in regard to password prompts.

You also now have finer control over the caching behaviour of passwords and the sudo behaviour via additional settings.

Settings rework

This update comes with a complete rework of the settings menu. Many options have been added and existing ones have been improved, with a focus on providing more control over security settings. Make sure to give them a read to discover new options.

There has been a big focus on providing finer-grained control over security settings, which can be especially useful in enterprise contexts.

Kubernetes configs and namespaces

This update adds support to also add connections from other kubeconfig files.

Furthermore, you can also choose to use any namespace you want. This is useful in cases where you have not set up a context for every namespace you have.

Temporary containers

You can now run a temporary docker container using a specified image that will get automatically removed once it is stopped. The container will keep running even if the image does not have any command specified that will run.

This can be useful if you quickly want to set up a certain environment by using a certain container image, e.g. a simple ubuntu image. You can then enter the container as normal in XPipe, perform your operations, and stop the container once it’s no longer needed. It is then removed automatically.

Quick access for connections

One common feedback that some users shared was that it could be quite cumbersome to access a specific nested connection as one would have to possibly expand several connections first. Expanded connections would then also take up a lot of space, leading to a lot of scrolling.

There is now a quick access button available for connections that enables you to quickly choose a connection in the hierarchy without having to expand any connection views.

Other changes

  • Add support for PowerShell on Linux and macOS
  • Add ability to easily add custom files to the git vault
  • Improve git vault performance
  • Fix scaling issues on Linux by providing a separate scaling option
  • Many more bug fixes

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

So if you gave this project a try a while ago or it sounds interesting to you, you can check it out on GitHub! There are still more features to come in the near future. Next up is probably RDP/VNC support. I also appreciate any kind of feedback to guide me in the right development direction. There is also a Discord and Slack workspace for any sort of talking.

Enjoy!

  • crschnick@sh.itjust.worksOP
    link
    fedilink
    arrow-up
    8
    ·
    9 months ago

    Sadly this is not possible due to the flatpatk sandbox, at least without having to rewrite basically the entire application. You can’t open other applications or shells from the sandbox, so nothing would work.

    Someone told me that it is possible in theory to reduce the level isolation of the sandbox via flatseal, but that would require the user to perform additional operations to make it even work. If it is not going to work out of the box, a flatpak version would not make a lot of sense.

    • leopold@lemmy.kde.social
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      edit-2
      9 months ago

      I’m pretty sure the sandbox level is chosen by the developers of any given application. Flatseal only exists for users to change the sandbox settings the developers have chosen.

      • crschnick@sh.itjust.worksOP
        link
        fedilink
        arrow-up
        3
        ·
        9 months ago

        Yes, the developer can choose a few sandbox permissions, however these options are limited. Even if I grant all permissions, I still can’t spawn a bash process from my flatpak application. Flatseal can grant additional sandbox permissions to allow that, but these options are not exposed for the developer.