On Thu, Apr 17, 2025 at 10:32:05AM +0000, Zaz Brown wrote:
>
> > 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
Honestly, for states that user create manually I find it easier to
simply edit the actual top file (top.sls) directly, instead of doing it
in two steps: creating new .top file and then enabling it. But if you
have more modular setup, the top.enable may be useful.
> > 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.
Look closer, see files in /etc/salt/minion.d/*.conf. Or simply ask salt
about the final value:
qubesctl pillar.get master:file_roots
> 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.
Indeed, looks like a mistake. But removing it now will likely break some
systems, as users may rely on one or the other already...
> > 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.
Yes, Ansible is definitely easier to use. And yes, there is a plan to
add official Ansible support. But I don't have any specific timeline for
that yet (I hope we'll squeeze it into R4.3, but we'll see).
But Salt will also remain there, at least for now.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
--
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/aADeRLFUYegd_aPV%40mail-itl.
signature.asc
Description: PGP signature
