> Mostly not having to worry about conflicts with standard formulas
> (virtual-machines and few more in more specialized cases), and all the
> automation to manage merged top file (qubesctl top.{enable,disable}).
> I don't think it's a huge concern, maybe avoiding the few names used
> there is still easier than dealing with two envs?
If we were to use two file_roots, I see the concern about conflicts. But
I was proposing simply a user directory: /srv/salt/user/ That should
result in no conflicts, while still allowing the user states to utilize
all the stuff available in the base environment.
As for qubesctl top.enable, are you saying that a new env allows us to:
qubesctl top.enable myState saltenv=user
and that's convenient? Wouldn't it be straightforward to change the
above to work as so (if we have /srv/salt/user/):
qubesctl top.enable user.myState
> Actually, there are already multiple file_roots for the base env, see
> /etc/salt/minion.d/*.conf. Adding another one should be fine IMO.
> Anyway, I'd rather avoid /srv/salt specifically, as this one is covered
> by the magic top management (see /srv/salt/top.sls), not exactly a thing
> for manual user changes.
I only see one file_root on my machine and on GitHub: /srv/salt.
Although there are two base pillar_roots: /srv/pillar and
/srv/pillar/base, but that seems very unusual. If I understand
correctly, that means anything in /srv/pillar/base can be accessed as
myfile OR base.myfile. My instinct is that this is not necessary and has
potential to cause confusion down the line.
> That's kinda my experience too, also outside of qubes. If something
> breaks, I usually add `-l all` and then search through pages and pages
> of output...
> As for dispvm, yes, there are also cases where some output may not be
> retrieved, I think internally salt makes some call with `-l quiet` or
> such. I don't think I needed such logs often, but when I do, I
> usually comment out `dispvm.kill()` line in qubessalt/__init__.py and
> then call relevant salt-ssh command manually (as seen in
> /etc/qubes-rpc/qubes.SaltLinuxVM). Far from ideal...
Is there any possibility of transitioning Qubes to an alternative, such
as Ansible? It seems to be much larger with more momentum and easier to
get started with, which is crucial to appeal to an audience who are
technically savvy, but not professional sysadmins.
I see we have https://github.com/Rudd-O/ansible-qubes by Rudd-O and
https://github.com/fepitre/qubes-ansible by Kushas Das and fepitre.
--
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/qubes-devel/87ldrz2i5d.fsf%40zazbrown.com.
