Sync appmenus in package postinst #2078
Comments
These are the only two VMs that will be visible on production systems and have specific tools we want users to be able to directly start. * sd-devices: Files (Nautilus) and Disks * sd-whonix: Anon Connection Wizard and Tor Control Panel Ideally we would do all of this in salt, but since we need to run stuff via dom0 after we do things in the VMs, it would require adjusting the order of some salt states, which is a bit too intrusive for a fix during the RC/QA period. A TODO indicates that this is not an ideal situation, and <freedomofpress/securedrop-client#2078> tracks one potential fix. Fixes #520. Fixes #1109.
These are the only two VMs that will be visible on production systems and have specific tools we want users to be able to directly start. * sd-devices: Files (Nautilus) and Disks * sd-whonix: Anon Connection Wizard and Tor Control Panel Ideally we would do all of this in salt, but since we need to run stuff via dom0 after we do things in the VMs, it would require adjusting the order of some salt states, which is a bit too intrusive for a fix during the RC/QA period. A TODO indicates that this is not an ideal situation, and <freedomofpress/securedrop-client#2078> tracks one potential fix. Fixes #520. Fixes #1109.
These are the only two VMs that will be visible on production systems and have specific tools we want users to be able to directly start. * sd-devices: Files (Nautilus) and Disks * sd-whonix: Anon Connection Wizard and Tor Control Panel Ideally we would do all of this in salt, but since we need to run stuff via dom0 after we do things in the VMs, it would require adjusting the order of some salt states, which is a bit too intrusive for a fix during the RC/QA period. A TODO indicates that this is not an ideal situation, and <freedomofpress/securedrop-client#2078> tracks one potential fix. Fixes #520. Fixes #1109.
|
Took another look cause based on the slightly complicated script stuff evolving in freedomofpress/securedrop-workstation#1112 it would be nice to keep it simple and out of dom0/into rpc. In the qubes-core-agent-linux package there's a post-install RPC (/etc/qubes-rpc/qubes.PostInstall) that runs all the scripts in If we make sure we conform to behaviour that |
These are the only two VMs that will be visible on production systems and have specific tools we want users to be able to directly start. * sd-devices: Files (Nautilus) and Disks * sd-whonix: Anon Connection Wizard and Tor Control Panel Ideally we would do all of this in salt, but since we need to run stuff via dom0 after we do things in the VMs, it would require adjusting the order of some salt states, which is a bit too intrusive for a fix during the RC/QA period. A TODO indicates that this is not an ideal situation, and <freedomofpress/securedrop-client#2078> tracks one potential fix. Fixes #520. Fixes #1109.
Description
Rather than syncing appmenus from dom0 (via Salt or scripted), when packages change we can request an appmenu sync via the built-in appmenu sync RPC call provided in (istr?) qubes-core-agent-linux in our own package's postisnt:
qrexec-client-vm dom0 qubes.SyncAppMenus /etc/qubes-rpc/qubes.GetAppmenusThe text was updated successfully, but these errors were encountered: