There isn't good support for nested RDP connections, didn't even know that some people used something like this.

But there is very good support for nested shell connections and tunneling RDP over SSH. If your target system isn't reachable directly and require something like a bastion host connection first, you can still connect via RDP if you use SSH tunnels over multiple hops in XPipe.

- When XPipe will open a terminal connection and you have specified custom shell environments / init scripts for a certain system, it will first automatically create a temporary init script on the target system in the background, which will be run as the login script only for that terminal launch from XPipe. That way it's noninvasive and doesn't change any existing configuration on the system

- XPipe acts as an askpass program for SSH, meaning that it can listen to any password requests made from the ssh client, forward that your password manager, and reply with the password that the password manager returned. If you password manager supports the SSH-agent, XPipe can also use it to supply keys for ssh as well.

The current KVM integration is actually more formally an integration for libvirt and the virsh command-line tool.

If your hypervisor is supported by libvirt, you should already be able to use it in XPipe.

If it does not support libvirt, then I guess this would need a separate integration. But I would have to look into that first as I have never used these tools you listed.

Interesting, haven't heard of that before. That is not supported right now, but I can look into it. It also depends how good their CLI works for me to integrate it

On macOS there are still a few reliability problems, mostly caused by misbehaving zsh extensions that I have to work around. I replied to your issue report, I think this should be fixable.

There's only one release build which contains all feature implementations, but some of them are locked behind the plans. So to some degree, they are artificial as there isn't currently a separate build for the Homelab and Professional builds.

The only service it relies upon is the licensing server, but if you also don't want to use that to be fully independent, you can request an offline license. You can find the details about that on the pricing page.

Right now, there's no direct import from WinSCP, next best thing where it can import from is Putty

Are you using the LTSC version on your desktop or also for some of your remote systems? I think if it's only for the desktop, I can fix that as that isn't really intended to be limited to the Professional version. Didn't really test it on an LTSC system so far, so I will look into that

On my desktop, but I am trying to access it "remotely" from the same machine. I have a Linux host and an LTSC KVM guest with GPU passthrough so I can cleanly isolate (and more easily reproduce) my Windows environment. Currently, I just use VSCode's Remote SSH to develop in Windows, but it leaves much to be desired.

Ah I see. The reason it complains now is that the LTSC systems are called Windows Enterprise LTSC, didn't even know that they fell under the Windows Enterprise category.

You can run XPipe on a local LTSC installation, you just can't connect to one remotely because it thinks that you are connecting to a Windows Enterprise server. I will think about how to solve this the best way, because that wasn't on my radar

That is true, but ideally with XPipe you can do that easier and faster. And with the time and effort you save each month, the few $ per month can be good deal for you.

it will not, i know how to write aliases.

Now I don't fully know the details of your setup, but in general XPipe just works on top of your kubectl installation. So it will only work if you could manually connect to your clusters via kubectl in a terminal. But you can always just try it out and see what happens the community version because I can't say that for sure.

Yeah, I'm assuming you're just calling kubectl directly underneath the hood. The way that aws-vault works is that you do something like: `aws-vault exec kubectl ...` or you can just do `aws-vault exec` and drop into a subshell. In both cases, a set of short-lived AWS credentials are exposed via the AWS-defined environment variables to the process (or shell context). The kubeconfig is then configured to handle authentication via AWS (rather than the default certificate method).

So, if you just straight-up call `kubectl` within XPipe without having AWS credentials already available, then it would fail. So, I'm guessing this wouldn't work.

I'm also an aws-vault user and wanted to draw your attention to the fact that kubectl supports exec based credential acquisition (in fact, that's how $(aws eks update-kubeconfig) emits them by default). Now, whether that fits your threat model is a different story, but it's for sure technically possible because I use that setup every day

By default, it looks like this:

    exec:
      command: aws
      args:
      - --region
      - us-east-2
      - eks
      - get-token
      - --cluster-name
      - my-cluster

but for us it would look like this:

    exec:
      command: aws-vault
      args:
      - exec
      - --region
      - us-east-2
      - my-vault-profile
      - --
      - aws
      # likely not required, but I'm including it for "coding in a textarea" :-)
      - --region
      - us-east-2
      - eks
      - get-token
      - --cluster-name
      - my-cluster

Yeah, I think something like that will be properly supported once I get around to implementing an aws integration in the future

Whoops, it seems like some links were not updated yet. That should be just https://docs.xpipe.io/cli

To preface that, the CLI is only very basic. The only real thing you can do with it is launch shell connections. For more advanced usage without the GUI, there is for example the Python API: https://docs.xpipe.io/guide/python-api