-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, Aug 17, 2016 at 01:42:36AM -0700, nekroze.law...@gmail.com wrote: > > > There are also a handful of other problems smaller problems I have > > > encountered while trying to configure everything I need with salt. For > > > example the fedora-23-minimal templates are unmanageable via salt, all of > > > the internal > > VM salt configuration just doesn't work on on them from > > > my experiments. > > > > It may be that salt requires some additional packages to preform its > > actions. Minimal template have really minimal package set installed. > > But you probably can install additional stuff using pkg.installed. > > Yes, it may require calling `qubesctl --all state.highstate` twice. > > I believe it says in the docs that the only requirements in the target VM for > salt inter-vm management to work is scp because ssh looks of it or something. > Turns out scp is not installed in the fedora-23-minimal template by default, > however, even after installing it the installation of a package does not work > for the minimal template. Using the revelation that is the --show-output > switch I can see this happening. > > Its quite long so here is a paste of the section of output pertaining to > fedora-23-minimal template http://pastebin.com/kCe29p9L but the tail of it is: > > stderr: > ln: failed to create symbolic link ‘/tmp/salt-shim-sandbox/scp’: > File exists > WARNING: Unable to locate current thin version: > /tmp/.root_d510cd__salt/version. > stdout: > ERROR: Failure deploying thin: /usr/bin/scp > _edbc7885e4f9aac9b83b35999b68d015148caf467b78fa39c05f669c0ff89878 > deploy > > ln: failed to create symbolic link ‘/tmp/salt-shim-sandbox/scp’: > File exists > WARNING: Unable to locate current thin version: > /tmp/.root_d510cd__salt/version.
It is already fixed: https://github.com/QubesOS/qubes-issues/issues/2207 > > In any case, if you put Fedora-based VM behind sys-whonix, and set it as > > UpdateVM, it should work. > > That does indeed seem to fix the problem. Is there a reason why the whonix > setup choice that uses whonix for dom0 updates not also build an update vm > that uses sys-whonix and is based off of fedora? Basic actions (install updates, new packages) should work in this setup and it save some RAM (no need for additional VM in addition to sys-whonix). > > > There are some aspects of configuring the dom0 experience in Qubes that > > > does not seem to be possible from salt. For example there is no way to > > > specify which applications are available in the menu for an appVM, > > > > Indeed there is no module for this, but you can simply edit > > `whitelisted-appmenus.list` file in the VM directory with file.managed. > > Then appmenus regeneration will be triggered at nearest template > > upgrade, which will probably happen a moment later anyway (as dom0 is > > configured before all the VMs). > > I have tried this and found it not to work. I have not been able to get the > application to appear in the application menu in xfce, nor is it enabled when > I view the VM's apps list in the qubes-manager. I can confirm the line is in > the right place from the state and matches the .desktop file in > /usr/share/applications which should be where it looks. I have not rebooted > yet but I have done multiple full highstate reruns on all vms after applying > this state. It wasn't until I booted up the template the appVM was based on > and ran qvm-sync-appmenus that it started to appear. I am still trying to > find a way to emulate this is a sane but simple way with salt. Currently qvm-sync-appmenus requires template to be running, but it should be easy to add an option to run without communicating with template (only regenerate VM entries, without syncing them with template). If you find this useful, feel free to open a ticket on github. > > Its "meminfo-writer" service (qvm.service). > > Brilliant. Poor assumption on my part that because there was a tickbox it > wouldn't match one to one for a service but I guess the tickbox is just a > redirect to the service for convenience from the memory tab. Yes, exactly. > > > BTW do you know a salt module for editing XML files - just like > > file.line or so? It would be really useful for configuring some desktop > > environment settings - almost all Xfce configuration is in XML files... > > The best would be augeas.change state which uses augeas which can make > modifying structured data type files a one line thing. Thanks, will take a look at it! > It would be perfect for this but has some dependencies (python-augeas) but I > am not sure if templates would need that installed or just dom0. For configuring dom0 - in dom0. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXxO1qAAoJENuP0xzK19csd5MH/3472Ab+NKYMafw2czzduZv6 An4aPXo+pSN90LI1YO9e3cLqbV52PuB3kAHtJZHmFnDM79JYqo+06/I0GnMXg89j ifRixYZw7VMMmz8AkOYBF2pBVSbX7G3TYsyPyV79ypcXI3qdVekb00P8qV86ialA OA+DMe2s7WUQcomZfqosN3kGoH2Z7hbb6x2/egIrU18K6WLPxOSMZ9U2zZZBfyf4 x6jBLtBzf1vHoL3erjbDFpA+NNDRl/N+Ozep72HhRU/oaZ3ZeHJTSuLsBYtt1CiA l2VGI/zsbgUN7JldIxr+U2/Nt/ICK4XA+QUDQyEtRMwylm8/Sp4hvn/pFMJl9Ig= =QiCx -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20160830022026.GV21245%40mail-itl. For more options, visit https://groups.google.com/d/optout.
