123

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:

Hub

Hub Alt

Browser

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.

Markdown

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

Scripts

Native window styles

The application styling has been improved to fit in better with native window decorations:

Windows style

macOS style

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!

you are viewing a single comment's thread
view the rest of the comments
[-] Luci@lemmy.ca 8 points 3 months ago* (last edited 3 months ago)

I'm going to take a look. Thanks for sharing!!

Edit: oh, I use Yubikeys for my home lab. Might not be an option for me without getting a paid license :(((

[-] crschnick@sh.itjust.works 3 points 3 months ago

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.

[-] asap@lemmy.world 3 points 3 months ago

I assumed that yubikeys would be found pretty much only in enterprise environments but perhaps I was wrong there.

As a datapoint, I am a home user and use Yubikeys. For example, they are one of the 2FA options supported by Bitwarden for home users.

I have recently trialed both NitroKey and OnlyKey to see if I'd want to replace my Yubikey with either of those, but the Yubikey is sadly superior. (Sadly because it's not as open as those other two options.)

[-] crschnick@sh.itjust.works 4 points 3 months ago

Do you use the normal one or the FIPS one? Maybe I can use that to differentiate between personal and commercial use

[-] asap@lemmy.world 2 points 3 months ago* (last edited 3 months ago)

Not the FIPS one, I use the normal 5 series.

Yubikeys are great because you can also add your TOTP codes on there, but require a physical touch to generate the codes.

You can do that with other products like the NitroKey as well, but the implementation is not as good - example the secrets are not encrypted on the NitroKey.

[-] crschnick@sh.itjust.works 3 points 3 months ago

Alright, I will have to look into whether it is possible to differentiate between normal and FIPS here

[-] Luci@lemmy.ca 2 points 3 months ago

I wouldn't mind trying an evaluation, would be nice to see how it works with RHEL and Windows Server as well. I also work in an enterprise and would love to compare it to our current tools, but I am worried it won't like our "PAM".

My homelab is a bit more advanced than most as I use it for education as well as having a badassed home network. So I use security keys in it to keep up with the enterprise.

I think you'll find security keys will be picking up steam with home users, it's nice to have that extra layer for public facing stuff and private VPSs.

[-] crschnick@sh.itjust.works 2 points 3 months ago

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.

[-] Luci@lemmy.ca 1 points 3 months ago

Yep, I'm kinda pushing it, I know! :))

I'll send you an email later in the day when I have a chance. Thank you for offering the evaluation.

this post was submitted on 01 Aug 2024
123 points (96.9% liked)

Selfhosted

40152 readers
466 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS