On Tue, Dec 06, 2022 at 10:12:49PM +0200, Vadim Likholetov wrote:
I’ll try to explain — running as user is not just dropping the priviledges, it is about preparing the environment - making home directory, fixing permissions, allocating pty-s in case of interactive sessions, setting environment variables. Many system daemons like dbus, pipewire , etc has their system-level and user-level parts and we should manage this separately — and it is our nearest future if we want some complex user environments to run on Spectrum, and possibly the packages for this daemons will extend this environment transparent to the user.
So it’s s another form of encapsulation like we discussed about making a separate layer for wayland.
Ah, thanks for the explanation. I understand now! You're quite right about running user daemons like PipeWire. I think to manage those, we'd want to run a user-level s6(-rc) instance, so that the services are supervised, and can therefore be restarted if they crash, and dependencies can be taken care of, and logs can be managed however that should work. Let's try adding PipeWire, D-Bus etc. daemons straight to the img/app image? It's intended to be the default image for running applications, so anything that an application is likely to expect to be running should be provided by that image by default. And then later on, when it comes up, we can figure out how to support adding extra services, or whether we should support removing default services from the image, etc. How does that sound?
I’ve published the cloud-hypervisor patches for extra user console device in my repository under -userconsole branch. I’ll test it (or anyone can) for side effects and then we can discuss if it worth to be used in Spectrum or pushed upstream of C-H. Here is the URL — https://github.com/vadika/cloud-hypervisor/tree/userconsole
On 6 Dec 2022, at 19:10, Alyssa Ross <alyssa.ross@unikie.com> wrote:
On Tue, Dec 06, 2022 at 05:57:19PM +0200, Vadim Likholetov wrote:
I’ve done this — I have patched cloud-hypervisor to have three console devices — serial, console and user-console, but than decided that this patches will never go to C-H mainline so got back with more traditional approach with tmux :)
I'd be pretty optimistic about the chances of a patch that just made it so you could provide multiple consoles the same way you can provide multiple block devices. Like "--console pty file=/path/to/console.out" on the command like to make two consoles, one going to a pty and the other to a file.
In Spectrum, the way I'd see such an approach working is that by default there'd be a single console that gave you a shell inside the VM, and if you needed other consoles for other reasons (e.g. if you had an application running on the console, like Lynx) you'd configure another console in the VM configuration. But as we move more towards graphical applications, it will probably become rare to need a secondary console for application interaction like that.
To get a non-root shell from the root console though, I think it should be enough to just:
# s6-applyuidgid -u 1000 -g 1000 sh
(Adding tmux to the VM in development to be able to hop between multiple shell sessions would be a reasonable thing to do, of course.)
On 6 Dec 2022, at 17:20, Alyssa Ross <alyssa.ross@unikie.com> wrote:
On Mon, Dec 05, 2022 at 12:42:35AM +0200, Vadim Likholetov wrote:
Cloud-hypervisor has virtual hardware limitations -- it supports only one console device and only one serial device. SpectrumOS is using serial device for kernel logs of appVM and console device as a console. To have access both to root-executed part and to user-executed part of the VM payload, I installed a tmux on console. Now, when you're running vm-console command you get access to the tmux and have the ability to switch between root and user consoles, that can be useful during debugging VM payload.
I wonder what it would take to make cloud-hypervisor support multiple virtio-console devices… I suspect it wouldn't be too hard, since it already supports multiples of every other virtio device just fine…