Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upAutomatically start nm-applet in the default (all?) netvm #137
Comments
marmarek
assigned
rootkovska
Mar 8, 2015
marmarek
added this to the Release 1 Beta 1 milestone
Mar 8, 2015
marmarek
added
bug
C: core
P: major
labels
Mar 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by smoku on 28 Mar 2011 12:22 UTC
Start nm-applet in default-netvm using /etc/xdg/autostart
|
Comment by smoku on 28 Mar 2011 12:22 UTC |
marmarek
unassigned
rootkovska
Mar 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Modified by smoku on 28 Mar 2011 12:52 UTC |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by joanna on 29 Mar 2011 00:18 UTC
We should provide a simple xdg startup script that would do qvm-run $(DEFAULT_NETVM) nm-applet.
|
Comment by joanna on 29 Mar 2011 00:18 UTC |
marmarek
changed the title from
netvm should automatically start NetworkManager and nm-applet
to
netvm should automatically start nm-applet
Mar 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by joanna on 31 Mar 2011 14:30 UTC
FWIW, it works without problem on netvm based on F13 template (the one I recently published). It doesn't however work on netvm based on the F14 template (again the one I published this morning)... Apparently this is nm-applet-specific thing.
A note that I'm running nm-applet as root (on F13). Perhaps if we could get it working as user it would also work in F14 (perhaps it refuses to show the icon because I start it as root?). Also, ability to run it as user might be closely related to #138.
|
Comment by joanna on 31 Mar 2011 14:30 UTC A note that I'm running nm-applet as root (on F13). Perhaps if we could get it working as user it would also work in F14 (perhaps it refuses to show the icon because I start it as root?). Also, ability to run it as user might be closely related to #138. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by joanna on 31 Mar 2011 14:31 UTC
Sorry, the above comment was meant for #134.
|
Comment by joanna on 31 Mar 2011 14:31 UTC |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by joanna on 1 Apr 2011 10:16 UTC
Seems like the best solution would be to use some autostart desktop scripts in Dom0 (/etc/xdg/autostart/) and execute:
qvm-run $NETVM -u root nm-applet
Questions:
- Do we want to do that for all netvms in the system or just the default one? Probably for all running...
- What if user starts some other netvms later?
We cannot just start nm-applet from within a netvm because the default netvm is started before the X sesssion in Dom0 starts.
|
Comment by joanna on 1 Apr 2011 10:16 UTC Questions:
We cannot just start nm-applet from within a netvm because the default netvm is started before the X sesssion in Dom0 starts. |
marmarek
changed the title from
netvm should automatically start nm-applet
to
Automatically start nm-applet in the default (all?) netvm
Mar 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by smoku on 1 Apr 2011 12:18 UTC
I guess this needs a more generic solution of putting it to XSession on the vmside.
We start the vmside X server by our gui-agent, so it could also launch fully working (but minimalistic) XSession on the vmside. We could put X applications required on vmside there.
|
Comment by smoku on 1 Apr 2011 12:18 UTC |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by joanna on 1 Apr 2011 12:21 UTC
Sounds reasonable. So, e.g. out qubes-core-netvm.rpm could put those scripts there?
|
Comment by joanna on 1 Apr 2011 12:21 UTC |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by smoku on 1 Apr 2011 12:28 UTC
I think NetworkManager-gnome already creates proper autostart files. We would just need to kick them in. Ie. by starting gnome-session vmside.
|
Comment by smoku on 1 Apr 2011 12:28 UTC |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by smoku on 1 Apr 2011 12:29 UTC
Launching gnome-session would probably also fix a problem with keychain store.
|
Comment by smoku on 1 Apr 2011 12:29 UTC |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Comment by joanna on 1 Apr 2011 13:13 UTC |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by rafal on 4 Apr 2011 16:21 UTC
Things to consider:
- We probably want to run gnome-session as "user", so that other applications can use it, too ? Unfortunately, I had problems with running nm-applet as non-root, NetworkManager has some access control, and allows connections only from root or, well, user authorized in some way. It needs to be investigated.
- We want nm/nm-applet in "real" netvm only, not in proxyvms.
|
Comment by rafal on 4 Apr 2011 16:21 UTC
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by joanna on 4 Apr 2011 16:30 UTC
Yes, we want run it as user. Also it would be nice to support apps that want to escalate to user via polkitd, e.g. system-settings-date, -printer, etc. Currently our appmeus for template just run those apps with '-uroot' switch. The problem is that polkit displays authorization prompt, but asks for the root password, which... we don't have in AppVMs (* in shadow). Can we change the behaviour of polkit somehow to not ask for the root passwd and just for pressing the OK button?
|
Comment by joanna on 4 Apr 2011 16:30 UTC |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Modified by smoku on 4 Apr 2011 20:22 UTC |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by smoku on 6 Apr 2011 20:39 UTC
Implemented in http://git.qubes-os.org/?p=smoku/gui;a=commit;h=ee3a572aeab80d066fb097a08c006d9e03bf3c21
gnome-session had way too much dependencies, so I approached myself.
Commit message:
In qubes the Xorg server is started by GUI-Agent.
This commit changes qubes_run_xorg.sh script launched by Agent behavior,
so it starts whole xinitrc session, not just XOrg server.
But we don't use full-blown GNOME or KDE session, instead we have
simplistic qubes-session script which only job (so far) is to parse
/etc/xdg/autostart and launch session applications defined there.
We do this mainly to get the NetworkManager Applet tray icon, but do it
in a generic way that may be usefull in the future.
qubes-session obeys usuall .desktop file keys like:
Hidden, OnlyShowIn and NotShowIn. It uses ''QUBES'' or ''vm_name'' as session
name string.
So, to enable an application for NetVMs only, add:
OnlyShowIn=NetVM
to the application .desktop file.
And to disable an application in all Qubes VMs add:
NotShowIn=QUBES
|
Comment by smoku on 6 Apr 2011 20:39 UTC gnome-session had way too much dependencies, so I approached myself.
In qubes the Xorg server is started by GUI-Agent.
So, to enable an application for NetVMs only, add: to the application .desktop file. And to disable an application in all Qubes VMs add: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by smoku on 6 Apr 2011 20:45 UTC
We can run the qubes-session as a ''user'' user, but this really does not give us anything now.
The session is shared and accessed by environment variables, and our qvm-run starts applications in a separate process tree.
We would need to implement a launcher that we exec at the end of qubes-session script, which then waits for "spawn process" commands. Then our qvm-run command backend would need to check whether we have a launcher waiting for a given user, and if so do not start process by its own but proxy to the launcher.
|
Comment by smoku on 6 Apr 2011 20:45 UTC The session is shared and accessed by environment variables, and our qvm-run starts applications in a separate process tree. We would need to implement a launcher that we exec at the end of qubes-session script, which then waits for "spawn process" commands. Then our qvm-run command backend would need to check whether we have a launcher waiting for a given user, and if so do not start process by its own but proxy to the launcher. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by smoku on 7 Apr 2011 11:43 UTC
gnome-session running as 'user' user and session environment save&restore implemented in http://git.qubes-os.org/?p=smoku/gui;a=commit;h=25d8ef4f05218c695d981f8048a668c0f2cec945
|
Comment by smoku on 7 Apr 2011 11:43 UTC |
marmarek commentedMar 8, 2015
Reported by joanna on 25 Mar 2011 14:29 UTC
None
Migrated-From: https://wiki.qubes-os.org/ticket/137