Hash: SHA256

On Fri, Aug 04, 2017 at 01:12:29PM +0200, Zrubi wrote:
> On 08/01/2017 01:02 PM, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 01, 2017 at 11:25:11AM +0200, Zrubi wrote:
> >> - The isntall process is really looooong. Not debugged jet but
> >> the creating initramfs seems to be running forever. But at least
> >> was successfull at the end :)
> > 
> > Is it just about initramfs and "post installation tasks" - compared
> > to the whole installation time? There may be some bug causing
> > initramfs being generated twice (or more...) - I think I've fixed
> > something like this before, but maybe not all the places.
> Yes, this is the case.
> But have no time to install it again and again to identify the root
> cause :(

I have some other installer issues to debug, so may look into this too.

> >> - the missing Qubes Manager is a pain. - the 'replacement' in the
> >> task bar is small and buggy: the tooltip? like thing is randomly
> >> shirk to unusable. But too samll in general. I have 40 vm's right
> >> now.
> > 
> > What do you mean by "randomly shirk to unusable"? Can you provide
> > a screenshot?
> #2970
> > What do you mean? Domains widget is specifically there to show you 
> > VM status.
> Can't see the networking stuff.
> The most important is (at least for me) the actual NetVM used by a Qube.

So, you switch netvm for VMs frequently? Doesn't it mean you should have
separate VMs, instead of switching one between two (or more) networks?

Anyway, adding such information to domains widget shouldn't be a big
problem. Just don't show it by default (see reasoning why dropping old
manager, in announcement post).

> >> - the 'new' Qubes firewall solution causing more confusions. -
> >> mixed iptables and nftables? why?
> > 
> > What do you mean by mixed? Setting for VMs are applied using
> > nftables if supported (Fedora), or iptables when not (Debian). Not
> > both.
> the default "self defending rules" are Iptables based, the VM traffic
> forwarding rules are nftables based.

Ah I see.

> Custom firewall scripts now have to handle both.
> My opinion that there is no real need for nftables until it can really
> replace iptables. We are using just a really few rules here and the VM
> based chains achievable by iptables too.

The main reason for nftables is to simplify custom scripts. If you
have nftables, qubes-firewall no longer flush standard tables - it
register its own. This means you don't need to re-apply own rules every
time qubes-firewall change something. And you can register own tables
before or after qubes-firewall.
And in theory you can still use iptables for your custom rules.

> BTW:
> I plan to continue the L7 filtering thing I started to play with. Can
> you point the related documentation - if any - or at least the VM side
> code processing the Qubes firewall rules please?

It's here:

I think you can extend one or both of those classes and use them instead
of default ones. Or submit a patch.
This code unfortunately do not have (yet?) nice interface to extend it
for other rule types.

> >> - even if Allow is the default policy I see a DROP rule at the
> >> end. Why? :o
> > 
> > To fail closed - if something goes wrong, there will be that DROP
> > rule at the end anyway.
> :)
> It should be decided by the user, by selecting default policy.
> IMHO Qubes should not try to override the user decisions.

If you choose to have default action "allow", there will be appropriate
rule just before it.

> >> - the default login screen is just ugly. I know that this is not
> >> the first priority, and not even a technical issue. But new users
> >> will see that ugly thing first. So it's should be a Qubes skinned
> >> one. at least.
> > 
> > Hmm, I do see Qubes logo in the background there. Do you have
> > something different?
> Nope, I see the qubes backround. :)
> But still feels like a bare naked login screen.
> IMHO this should be just as important as the Qubes boot (splash) screen.

Which also have similar aesthetic.
Do you think about just some better background there, or some bigger

- -- 
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?
Version: GnuPG v2


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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to