How to interact with existing services using websocket interface

[AM44000]

Hello everyone,

I recently test and play with cockpit project and I would like to use it in my environment.

However, I have some constraints with existing services using websocket interface. Here is a summary of my network architecture:

I can only use the existing open SSH port between computers A and B, that's why I installed cockpit-ws under computer A and only cockpit-bridge under computer B.

Now I'm wondering how I can interact with the existing services A and B :

• For the service A, I think that a direct websocket connection from React page could be used as explained in this issue : Help with websocket #16489. But perhaps, there is a better solution?

• For the service B, it's more obscur for me :

  • Does I have to create my own cockpit bridge respecting the channel protocol?

  • Is there a way to use cockpit session to open another SSH tunnel?

I know that there is the HTTP / REST API but I prefer using websocket instead.

I would really appreciate any help.
Thanks you!

Regards.

[martinpitt]

Hello @AM44000 ,

I'm afraid we have to decompose this a bit.

I can only use the existing open SSH port between computers A and B, that's why I installed cockpit-ws under computer A and only cockpit-bridge under computer B.

Yes, that's correct. We generally recommend to not install cockpit-ws on production machines, and only connect to them through SSH.

Now I'm wondering how I can interact with the existing services A and B :

To make sure, "service A/B" is nothing cockpit related -- it's a system service similar to, say, udisks or podman or libvirt, which just happens to have a websocket API instead of CLI/DBus/HTTP/Unix socket?

Do you create a custom cockpit page which tries to interact with this service?

* For the service A, I think that a direct websocket connection from React page could be used as explained in this issue : [Help with websocket #16489](https://github.com/cockpit-project/cockpit/issues/16489). But perhaps, there is a better solution?

You sort of can (with the mentioned Content-Security-Policy), but bear in mind that this is entirely sidestepping cockpit. It requires that your browser can directly connect to the target machine's service A websocket, which only works if (1) the browser runs on computer A, or (2) the websocket listens on all interfaces.

All cockpit pages are implemented with the cockpit API, which makes these connections (running CLI programs, doing D-Bus calls, connecting to TCP/Unix ports) through the bridge. cockpit.http() comes closest, but it does not have direct websocket support, only HTTP.

* For the service B, it's more obscur for me :

It's not that different. Case (1) from above doesn't apply (browser doesn't run on computer B), so this would only work if the websocket accepts remote connections.

  * Does I have to create my own [cockpit bridge](https://cockpit-project.org/guide/latest/packages.html#package-bridges) respecting the [channel protocol](https://github.com/cockpit-project/cockpit/blob/main/doc/protocol.md)?

That could work, but it's not practical -- implementing your own bridge for first-class websocket support is a lot of work, and there isn't much precedence to learn from.

But websocket is just HTTP underneath. So it's worth trying to actually use cockpit's HTTP bridge API (which you already found) through a raw channel. You can think of this a sort of "ssh port forwarding", and it gives you a TCP-ish socket in your cockpit JS code that is connected to a remote http/tcp/unix port. This works fine through ssh as well (i.e. computer A and B). We use these in a variety of places, like cockpit-machine's VNC viewer. Probably the easiest example is https://github.com/cockpit-project/cockpit/tree/main/examples/xhr-proxy . You then open a websocket connection to that "magic" URL /cockpit/channel/... instead of directly, say, ws://localhost:1234 (i.e. the websocket URL of service A). I am not entirely sure if you need to open a http or a plain TCP stream channel.

This all needs some experimentation, and I'm afraid there's no precedent -- OS services which only talk websocket are rare, I have never seen one. HTTP/REST are common, but not websocket.

  * Is there a way to use [cockpit session](https://cockpit-project.org/guide/latest/cockpit-login) to open another SSH tunnel?

cockpit-session doesn't do SSH. cockpit on computer A uses the actual /usr/bin/ssh to connect to computer B. Also, this is the wrong conceptual level for this.

[AM44000]

Hello @martinpitt,

Thank you for your answer.

To make sure, "service A/B" is nothing cockpit related -- it's a system service similar to, say, udisks or podman or libvirt, which just happens to have a websocket API instead of CLI/DBus/HTTP/Unix socket?

Yes you are right, the existing services are not related to cockpit and they only have websocket API.

Do you create a custom cockpit page which tries to interact with this service?

Not for the moment but I will do it as soon as possible. For the moment, I want to be sure that I am in the right direction before coding something.

You sort of can (with the mentioned Content-Security-Policy), but bear in mind that this is entirely sidestepping cockpit. It requires that your browser can directly connect to the target machine's service A websocket, which only works if (1) the browser runs on computer A, or (2) the websocket listens on all interfaces.

In my case, the webbrowser will be executed directly on computer A, that's why I think it's the best and simpliest solution for service A (even if it will not use cockpit API).

But websocket is just HTTP underneath. So it's worth trying to actually use cockpit's HTTP bridge API (which you already found) through a raw channel. You can think of this a sort of "ssh port forwarding", and it gives you a TCP-ish socket in your cockpit JS code that is connected to a remote http/tcp/unix port. This works fine through ssh as well (i.e. computer A and B). We use these in a variety of places, like cockpit-machine's VNC viewer. Probably the easiest example is https://github.com/cockpit-project/cockpit/tree/main/examples/xhr-proxy . You then open a websocket connection to that "magic" URL /cockpit/channel/... instead of directly, say, ws://localhost:1234 (i.e. the websocket URL of service A). I am not entirely sure if you need to open a http or a plain TCP stream channel.

I will try to explore this solution in details. If I understand well, using an opened HTTP socket, I will have to recode websocket protocol in the React page?

This all needs some experimentation, and I'm afraid there's no precedent

Yes, I will have to spend a few nigths experimenting with this :)

cockpit-session doesn't do SSH. cockpit on computer A uses the actual /usr/bin/ssh to connect to computer B. Also, this is the wrong conceptual level for this.

Reading (again) the cockpit API, I'm thinking about another possibility (not sure for the moment): rewriting the existing service B to move it on the computer A (and so using the first solution with direct websocket communication). But in this case, instead of using service B websocket API on the remote computer B, I will have first to transfer a huge file (1GB or more) and I'm afraid about doing this under React page with cockpit-file...

That's why I talked about cockpit session: I understand this is not the thing I'm searching for but is there a way to use existing SSH tunnel opened by cockpit from a local service on computer A? In fact, I don't want to manage the SSH credentials twice, it will be great for me to reuse the cockpit login session from the rewirted service B to transfer the file using SCP for example (and not a process in React page executed in the web browser).

Regards.

[martinpitt]

That's why I talked about cockpit session: I understand this is not the thing I'm searching for but is there a way to use existing SSH tunnel opened by cockpit from a local service on computer A

That's exactly what a "raw cockpit channel" /cockpit/channel/... does. It connects to the remote file/socket/http port through the existing cockpit login, which can be over ssh. For example, in a VM I can start python3 -m http.server -b localhost (so you can only connect from localhost). Then in cockpit (I am doing this in the browser's JS console) you can open a channel which "tunnels" a HTTP request to localhost:8000 on the remotely connected system:

const ch = "/cockpit/channel/" + cockpit.transport.csrf_token + "?" + window.btoa(JSON.stringify({payload: "http-stream2", method: "GET", port: 8000, path: "/"}))
resp = await window.fetch(ch); await resp.text()

gives the HTML directory listing of whichever directory you started python3 in.

I am testing this with websocat instead of a HTTP server: ./websocat -s 8000. Then using the same ch as above:

const wsock = new WebSocket("ws://" + window.location.host + ch);
wsock.send("hello");
wsock.close();

This doesn't fail, but it also doesn't actually send anything. It even succeeds if nothing is listening on port 8000. That's what I meant with "experimentation" and "no precedent" -- this ought to work in general, but something gets lost along the way.