-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, Jan 16, 2017 at 11:24:13PM +0100, john.david.r.smith wrote: > hi. > i played around with salt and noticed a few things/ have some questions: > 1) > even when some states fail for some vm, the cli tool displays ok. it would > be better, if it displayed error in case of an error (some errors are > displayed).
Can you provide example error which wasn't detected? Regardless of the result, output is logged to /var/log/qubes/mgmt-*.log in dom0. > 2) > what happens if i have not enough memory to start a management vm? is there > something to counter this problem? (e.g. detect this case, limit the number > of management vms started at the same time and retrying the action) Currently number of concurrent instances is hardcoded to 4. We'll add an option for that, but probably not soon. It's here: https://github.com/QubesOS/qubes-mgmt-salt/blob/master/qubessalt/__init__.py#L191 This argument is not provided by /usr/bin/qubesctl, so default value (4) is used. If you want, you can add it here: https://github.com/QubesOS/qubes-mgmt-salt/blob/master/qubesctl#L79 In any case, you can retry, using --targets option and probably also - --skip-dom0. So to retry only 'debian-8' configuration, execute: sudo qubesctl --skip-dom0 --targets=debian-8 state.highstate > 3) > is there a plan to add some way of configuring dom0 (including service > permissions, default vm/template/etc, changing copy&paste shortcuts...) You can use any of standard salt module, there are plenty of them. For example file.prepend (of file.managed for more strict cases) is enough to configure /etc/qubes-rpc/policy/... > 4) > how much of the salt interface is subject to change? Not much. While working on Qubes 4.0 we try to keep compatibility as much as possible. But some minor changes probably will be unavoidable - we'll list them in release notes. > 5) > are there plans to add some functionality to the interface? Yes, "qvm" module will be extended for new features in Qubes 4.0. Is it what you've asked about? We were thinking about some own module for qrexec policy, but since default 'file' module cover most of the cases, we've abandoned that idea. I think there is currently no sane way to setup global defaults (other than cmd.run: qubes-prefs ...). So, we'll work on that too. > 6) > currently i really don't like the way the configuration works. > i have a top file where i execute some states for dom0 > these states create and configure my vms. > then in some top files i choose some vms and configure them again (but this > time it is some config i am doing in the domu). > > so it kind of looks like this: > top.top > ----- > base: > dom0: > - create-cfg-vm1 > vm1: > - some-cfg-in-domu > ---- > > now i have two layers of configuration (in top and sls). > for some config stuff i have to change a sls and for other i have to change > the top > is there a plan to change this? > > e.g. some kind of virtual minions? > > i would like to write something like this: > top.top > ----- > base: > dom0: > - copy-sequence.Strg-Alt-Shift-C > vm1: > - create #this affects dom0 > - color.red #this affects dom0 > - netvm.sys-tor #this affects dom0 > - mail #this affects domU > ---- > then i could see all my domU config in the top file. > > i currently hacked something but this only works in a sls file and for dom0 > config (but has this style of syntax) > > i am currently looking whether i can do the same in a top file (but i doubt > it, since there is no templating in top files) And the last sentence is exactly the reason why it's tricky to have it in one place. Rendering sls files (may) require getting data (grains) from target system and we don't want to parse that data from VM in dom0. To limit attack surface. So, we can't render sls for VMs in dom0, we need to decide what goes where at 'top' files level. I think the only think that can be improved here, is some "automatic" creation of VMs mentioned in top file - something like you've described above. But it's tricky to do it, while keeping flexibility of salt... Using valid salt syntax like yours, to achieve different effect looks like asking for troubles. If going that way, IMO it would be better to have something that isn't valid salt syntax here and have a pre-processor script to create actual salt configuration. > concerning this i also have some other questions > > how is the order of execution? > will dom0 always be executed before any domU is started? Yes. In particular you can create VMs using states for dom0, just to have them configured a moment later using states for VM. > when are the files for domU read? > after dom0 is configured? (then i could write state files during dom0 > configuration) Yes, those files are loaded just before configuring VM. > (if you want i can upload my scripts when i am done) > 7) > is there some documentation on the custom salt modules added by qubes? (i > may want to extend them) Yes, see links at the end of https://www.qubes-os.org/doc/salt/ > 8) > is there some way to execute some dom0 scripts after configuration of domu? > (e.g. trim-template) Currently no. > 9) > the fedora-24-min template can't really be configured with salt. > there is the package file missing. > after i installed the package i still got an error: "Target 'fedora-24-min' > did not return any data, probably due to an error. exit code 20" The important thing is what is your default template - it is used for that intermediate VM from where target VMs are configured. Is it also fedora-24-min? salt-ssh requirements in the target VM are really minimal - I think any shell + python should be enough. For me it works, but it's possible that my minimal template is no longer such minimal... Ok, tried on fresh minimal template and found the problem: sudo So, packages needs to be installed: - file - sudo And also cleanup ~/QubesIncoming/disp-mgmt-* in the template, because it isn't removed after failed run... > any idea how i could fix this? > or where i could get more data. e.g. are there some salt logs in some vm > (e.g. in the domU)? /var/log/qubes/mgmt-*.log That's the only thing that is preserved. > there probably are files in the management vm, but this vm gets deleted. > is there an option to stop the deletion of the management vm? There is no option for that, but you can suspend qubesctl execution (Ctrl-Z) to prevent that. You need to do that when you see that target VM is being starting (at this moment dom0 have already send all required data and all the execution is in management VM). The above I've debugged exactly this way: 1. Ctrl-Z on qubesctl. 2. Open terminal in disp-mgmt-fedora-24-minimal. 3. Look at /etc/qubes-rpc/qubes.SaltLinuxVM - this is what is executed. 4. Get the last two lines and execute them, fix problems, repeat. Those lines: export PATH="/usr/lib/qubes-vm-connector/ssh-wrapper:$PATH" salt-ssh "$target_vm" $salt_command Of course adjust $target_vm (fedora-24-minimal) and $salt_command (state.highstate). - -- 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 iQEcBAEBCAAGBQJYfY+RAAoJENuP0xzK19csEHcIAIQvqN9CldAxkY4OVUBBYB3b C1tMuiYkGPEzyfcE+5J6QaNzGXOXf2i/lm+7HUKRnMN42bmYdLLVCFrHUcxn09lD uDGid2kwOkhX17RhZf5FyMhhXETIutQGDw/gJK9bUl8k8gczYjY4ek1RGPSFnjYe 3T0BbUFKNeiJzD3i1hCNj5T2xOTpVcURWuIj4AuABl7QESg+OuEYJg2e4cJW+Ibl 8obVMLZcZ/rLT8IMzjHB1IOzuxI8UXiT3Qg4SLE8xmV+z8lqYI2wK3atCJfmWuYn ZfgTuhxg9LPD/b8ILMmJQfykENefqBR549INpL8b1WdXqQZK7JME3Xa7veZkehQ= =yUaE -----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/20170117032920.GC3974%40mail-itl. For more options, visit https://groups.google.com/d/optout.
