Running Waydroid Remotely in a VPS and puppeting it from Librem 5 or Laptop

Software
1

Hi. I mentioned this long ago in another thread, but for a while I have been doing the thing where I remotely use Waydroid, but keep the Waydroid confined to run on a VPS rather than to run it on the Librem 5, so that my Librem 5 can stay clean and nice without Waydroid actually on it.

But what I didn’t describe much was that this solution always had a problem. Starting up waydroid inside the remote-control VPS didn’t work from the Librem 5 because the VNC client I was using was (for some reason) unable to forward keystrokes from the Librem 5 virtual keyboard, whereas Librem 5 with a physical keyboard, or Librem 14, could control the VPS perfectly.

This meant I was actually using my Librem 14 really, and not the Librem 5. But I was thinking about going on a trip soon where I only have the Librem 5, and I might want the Waydroid working and available for that entire trip.

So last night I mucked about with the settings on this and I ended up breaking the Waydroid install on my server. After a bit, I fixed it. But on top of fixing it, I figured that in case something bad ever happens to that VPS again I should publish more about what I was doing so that it can be used by others.

To that end, I created a codeberg repo with all my shell scripts I was using and stuff, and my notes, including the newer versions I made last night that allow me to SSH into the headless VPS, launch sway window manager with remote controls enabled, and launch Waydroid inside that sway instance, all from the headless SSH connection before ever connecting. This allows me to deal with the fact that the Librem 5 VNC viewer I was using only has touch functionality and not keyboard.

I don’t know if this will be useful to anyone else, but in case it is, here is my codeberg repo:

That said, this is basically a repo with a bunch of bash scripts in a nonstandard organization, so I’m sure in the future someone might suggest a better way to do that which might better follow some established paradigms. I wasn’t so focused on that initially as I was just putting this out there so that it might be available to others (or to my future self if my VPS dies).

5 Likes
2

Nice.

… and got me thinking. If this would be taken further, there would be a bespoke L5 app (or as even Purism service) that from a GUI would automatically set up remote instances on servers and create launch icons on posh/dekstop etc. It could solve some of the L5 challenges, like not having enough resources (CPU, memory, storage) and needing the nasty stuff, by offloading them, like with these scrips. We’ve had similar mentions with individual use cases and apps (I suggested running private AI model) but this should be an upgrade, a polished capability of the phone, that makes it more comparable with modern phones. Right now it’s just scrips and hacks. I see potential for individual users as well as for the organization side, who could then apply some classic security management on organization servers and resources.

2 Likes
3

The organization term for that is thin client:

Thin client - Wikipedia (on my Wikiless instance)

They are typically used in libraries, where one “highly secured” server hosts all of the applications, while the various computer terminals connect to it via login portal.

1 Like
4

Close, and in general yes, but I think there’s room to develop the idea more towards something specific.

1 Like
5

Qubes Air is quite specific:

1 Like
6

Excellent find. That’s actually going even further and my original musings could be a kind of middle option between Qubes-as-a-sevice/cloud and having nothing in this area. Also, instead of general QubesAir there’s still room for L5 specific app/service. And instead of full cloud, user should have the option of using their own server (may be less secure but gain on privacy). For a read, from that blog article:

Above, we discussed how it’s possible to move Qubes VMs from the user’s local machine to the cloud (or to physically separate computers) without the user having to notice. I think it will be a great milestone when we finally get there, as it will open up many new applications, as well as remove many obstacles that today prevent the easy deployment of Qubes OS (such as the need to find and maintain dedicated hardware).

However, it’s important to ask ourselves how relevant this model will be in the coming years. Even with our new approach, we’re still talking about classic standalone desktop applications running in qubes, while the rest of the world seems to be moving toward an app-as-a-service model in which everything is hosted in the cloud (e.g. Google Docs and Microsoft Office 365). How relevant is the whole Qubes architecture, even the cloud-based version, in the app-as-a-service model?

I’d like to argue that the Qubes architecture still makes perfect sense in this new model.

First, it’s probably easy to accept that there will always be applications that users, both individual and corporate, will prefer (or be forced) to run locally, or at least on trusted servers. At the same time, it’s very likely that these same users will want to embrace the general, public cloud with its multitude of app-as-a-service options. Not surprisingly, there will be a need for isolating these workloads from interfering with each other.

1 Like
7

There is a clear issue in that an Internet connection is required to access these services, whereas I would much rather prefer the Librem 5 hardware being more substantial for hosting locally. That being said, if possible, remotely accessing an Android device for dealing with mobile device challenge response authentication may be better than using Waydroid.

1 Like
8

Good point.

For me though the actual duopoly apps that I am forced to use require internet access anyway. So strictly offline, local hosting isn’t a solution.

2 Likes