Any integration points with Pangolin Server in the roadmap?

Thanks for sharing on what’s upcoming, roadmap. May I request to consider integrating with Pangolin Server. It’s very user-friendly, especially for remote access with integrated authorization / identity management. Thought I’ll pass it on for whatever it’s worth :slight_smile:

Nothing planned but I also don’t think there’s really anything needed here.

If you have a site running IncusOS, you’d simply run the Docker image of newt as an OCI container on IncusOS, that will connect to your Pangolin server and can then forward to anything running within the site.

1 Like

Thanks for sharing. I am doing slightly different. I am located in California, running a Pangolin Server instance on AWS and accessing my incus server that I left at my friend’s place in Chennai, India :slight_smile: I am running ‘newt’ on a separate embedded board which is on the same subnet as my incus server (that way I can reach the rest of the machines). I am able to reach webui of incus server using lxconsole (attached). But accessing a VM’s Console is still an issue. May be I am not doing it right.

But setting up LXD WebUI remotely is still an issue as I am believe (as per google search) SSL termination happens at Pangolin Server and hence self-signed certificates on incus server doesn’t come into picture. So I could never go pass the initial screen configuring with LXD WebUI. Anyways, hopefully configuring LXD WebUI will become easier sometime in the future. Thanks again!

Ah yeah, you’d need to use OIDC authentication to deal with your proxy terminating the TLS connection.

1 Like

Pangolin comes bundled with Identity management which should hopefully make things easy.

Hoping to use Zitadel ( GitHub - zitadel/zitadel: ZITADEL - Identity infrastructure, simplified for you. ) as the UI looks pleasing and gives an impression of being very user friendly (though I am still struggling). For now, learning a lot from this course. https://www.udemy.com/course/oauth-2-simplified/ Thanks again!

Zitadel works fine, that’s what I’m using for my production clusters. Only rough spot was if you to use a specific claim (like preferred username or email) as the Incus identifier as unfortunately Zitadel only includes those claims in the ID token, not the access one.

But thankfully they have a built-in extension mechanism (actions) which you can use to extend the claims included in specific tokens including the access token, so after a bit of trial and error, I now get the email claim through and can use that as the identifier instead of the Zitadel user id.

Thanks again for sharing. Will make a note of everything you said.