date:20191123

[qubes-users] Re: xkb compose confusion

2019-11-23 Thread Ben Mulvihill

On Fri, 2019-11-22 at 06:50 +0100, Ben Mulvihill wrote:
> I use the "US international with dead keys" keyboard
> layout as a convenient way of getting accented characters. 
> 
> The keyboard is defined in:
>   /usr/share/X11/xkb/symbols/us
> and the dead key combinations themselve are in:
>   /usr/share/X11/locale/en_US.UTF-8/Compose
> 
> I am currently customising the dead key combinations.
> This can be done by copying
> /usr/share/X11/locale/en_US.UTF-8/Compose to ~/.XCompose
> and making modifications there. But I have noticed a
> discrepancy  between Fedora and Debian VMs.
> 
> The default settings in Debian and Fedora are identical.
> In particular they both contain the line:
>     : "ć"
> This implies that if I type a single quote followed
> by the "c" key I should get the character "ć" (unicode
> character U0107 or hex c487).
> In Debian VMs, this is indeed what happens. But in Fedora
> VMs, I get "ç" (unicode character U00E7 or hex c387).
> 
> [If by way of experiment (in Fedora), I modify another
> line, setting, for example:
>     : "ć"
> then I can get the "ć" character by typing a single quote
> followed by the "v" key.
> I can also modify the   line to obtain
> something completely different. For example:
>     : "Y"
> does indeed give me the character "Y" when I type a
> single quote followed by "c".]
> 
> It seems as though in Fedora (but not in Debian)
> there is some other mechanism which is overriding
> some, but not all, of the xkb compose settings. Does
> anybody know what is going on?
> 
> Thanks in advance.

To answer to own question, the guilty party was ibus.
Fedora enables this input method in gtk by default for all
languages, not just Chinese, Japanese and Korean as I
thought.  

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1574579951.1865.8.camel%40gmail.com.

[qubes-users] Excessive swapping & non-optimal qmemman heuristics

2019-11-23 Thread Jean-Philippe Ouellet

Hey all,

Am I the only one who seems to have noticed chrome reaching max mem &
swapping way more often than used to happen in the past? Some of my
workflows result in having a bunch of tabs (not even _that_ many,
maybe 20-30+) open in DispVMs. Unfortunately, this reaches the 4gb max
pretty quickly, and causes swapping, which results in the whole VM
becoming pretty unusable (can't even interact with it enough to close
tabs - often end up doing qrexec calls to pill the highest-mem chrome
renderer process - essentially me being a manual OOM killer).

I've also noticed some VMs getting more memory than it makes sense,
for example minimal VMs that just have a text editor, some notes, and
a few terminals open often end up with 1200mb+ pre-allocated when they
have no reason to need that much, which results in not having enough
unallocated mem to be able to start new domains unless you shutdown
VMs (that have accumulated large allocations while still having a
small user-meaningful working set).

Qubes has always been memory-hungry, and I've always considered it a
worthwhile tradeoff, but now I feel like I need to upgrade to a 32gb
machine just to run a couple browsers - this is getting ridiculous.

I'm going to look into this more systematically (first try tweaking
the qmemman algo, then maybe experiment with tmem), but I figured I'd
just rant here first in case anyone happens to have looked into this
already (beyond the usual "limit dom0 & sys-* maxmem" which seems to
always get parroted whenever this subject comes up).

Cheers,
Jean-Philippe

P.S.: Here's a script to tail qmemman's logs while translating from
xen domain IDs to VM names (because qmemman is purposefully simple for
reliability, avoiding taking a dependency on qubesd nor making extra
xc calls to get the name, so doesn't do this translation itself). Has
been helpful in seeing what's going on when things aren't behaving as
expected:
#!/bin/sh
journalctl -f -n 100 -u qubes-qmemman \
| sed -u -r 's/\.[0-9]+//g' \
| $(
qvm-ls --raw-data --fields xid,name \
| grep -v '^-' \
| sed -u \
-e 's/^/-e s\/([^0-9:])/' \
-e 's/|/([^0-9])\/1/' \
-e 's/$/2\/g/' \
| xargs echo sed -u -r
) \
| sed -u -r \
-e 's/([^[p])([0-9])[0-9]{3}([^0-9]|$)/\1\2k\3/g' \
-e 's/([0-9])[0-9]{3}k/\1m/g' \
-e 's/([0-9])([0-9])[0-9]{2}m/\1.\2g/g'

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_Dwpvxgghf4F2N7cLgbCgZGW9%3Dr2fM1jeDQxQRGhkwN0w%40mail.gmail.com.

Re: [qubes-users] Keyboard Shortcuts to Start / Shutdown any AppVM

2019-11-23 Thread beppo

Am 23.11.19 um 19:52 schrieb Daniil Travnikov:
> Could anyone know is it possible to use shortcuts / hot keys in Dom0?

If you use xfce, you could create a custom shortcut. It should point to
a script, you wrote, which toggles the vm-state. deppend on it's state
it run's qvm-start or qvm-shutdown for instance.

beppo.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b7204d44-63dd-2d3f-2010-4a85b7bb84e1%40posteo.de.

[qubes-users] Keyboard Shortcuts to Start / Shutdown any AppVM

2019-11-23 Thread Daniil Travnikov

Hi,

Could anyone know is it possible to use shortcuts / hot keys in Dom0?

For example I want to Shutdown about 10 AppVM's which already turned on. 
And it would be easier if I could Stop them using Hot Keys from keyboard.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c5e42120-5ced-4fc2-9d08-e334022d7e7f%40googlegroups.com.

Re: [qubes-users] How do I hide sys-net and sys-firewall from the list of available NetVMs?

2019-11-23 Thread donoban

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2019-11-22 22:07, swisspal...@firemail.cc wrote:
> Hi,
>
> I would like to hide both sys-net and sys-firewall from the list
> of available NetVMs when I create a new qube or when I modify a
> qube.
>
> The reason for this is that I sometimes create and delete many
> qubes

If you are using Qubes Manager you could modify 'create_new_vm.py' and
'settings.py' on '/usr/lib/python3.5/site-packages/qubesmanager'
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAl3ZfjgACgkQFBMQ2OPt
CKUirg//QJIiMmHdA3+9KvSE+YmxecDIpoIfN7fER7PuZakziFNrXeo/z1sY7YOQ
wa3Rqszv0n8xOYm71PI5pbLD5q1f0NuV+YJPYKj9XPATl6Nky/qAht0g+I5/m3+f
VD6/LMXxx5GpUizPYMOZtLv6AK0I+K4p+2joaOg4a8Ct9AFaJ20Lcn6/gBm9Opv6
GyGhYA2BC54TH1LbcoYje08opofK01U243Q6l+/YMiuhASKY5WZnqzjRqG6EkePx
n5rqvPde7NBpi/88QYy5kkSVWyz3gVZUD4DSyrPwz2kgWIw+dAiEEOxYfMcj4vtV
Bdj1PU2xfDoRtDHqTdnFzI3pP+F96Hj/cRSvjMhKgOjx6iXvzyrGa+pTa/Kr7bup
G3xt7R9B+/cl1THQo8097ZDXc/N2wi+3cPO4yXD8URbi9rnGpKN9A19kEMdTpN3p
cLpXft37qT/1bBRQUvS0kW4v5imBFjNbWsXk6QDtZD8Dl7fvvCIp1id1NJM5dEf6
10BtWSfdAIsa52PWc+w/t5/LbCgYAFLaj5M4FZIH+o8NWCJY/BF7la6NlOMoLRoL
23CANU4KyWE/hDCxbtiIm0bLTMNYSW0pOJlzuZupwMXW4j2DNPuFe7YUP24fIdNz
pjf56JMuaYFPf8qddCl6fOFnHXg2uLfFfRs/tHiZ2AS5oDxzHrU=
=Cna0
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0b041f15-a580-c517-8e42-72a9179f6349%40riseup.net.

Re: [qubes-users] Could use some help with my iptables configuration

2019-11-23 Thread Chris Laprise

On 11/23/19 9:33 AM, swisspal...@firemail.cc wrote:

Hello,

I want to achieve the following:

sys-net should only be accessible by sys-firewall and sys-firewall
should only be accessible by sys-whonix.

No AppVM should be able to connect to the internet if I set sys-net or
sys-firewall as NetVM. Internet access should only be possible via
sys-whonix.

What I tried so far is:
I flushed the INPUT chain on sys-net and applied these 2 commands

sudo iptables -I INPUT -i vif5.0 -s 10.137.0.6 -j ACCEPT

(10.137.0.6) is the IP of sys-firewall

sudo iptables -I INPUT -i vif5.0 -j DROP

This configuration already kind of works. If I create a new AppVM and
connect it to sys-net then I can not even ping sys-net anymore.

But then I noticed that another vif interface on sys-net came up as soon
as I connected the new AppVM. This is confusing me as I'm afraid that
that could lead to potential leaks in the future.

I am unsure how I should proceed with the configuration of this setup. I
don't know much about networking and especially because it is on Qubes
it's a bit more difficult to be sure of how things work.

I presume that I probably should make a specific NAT rule but I really
have no clue.

What I also don't understand is:
- Are the IPs that are assigned to the VMs static or do they change over
time? If they change, can I make them static?

IIRC they're dynamic.

- Will the flushing of a chain in a fresh VM interfere with the
functionality of the VM? I saw QBS-Forwarding rules and so on. I guess
it's not a good idea to delete those.

QBS-Forwarding will stomp over what you try to add there. Its managed by
Qubes. However, it exists in order to allow FORWARD to be user-managed.

One way to do it might be to allow only one downstream vif in
sys-firewall: Add a general eth0 block on top of the FORWARD chain.
Then, have a script that waits for the first vif to appear; when it
does, add FORWARD rule to allow it, then exit the script.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/767b2063-be96-3883-d9db-912690f059fc%40posteo.net.

[qubes-users] Could use some help with my iptables configuration

2019-11-23 Thread swisspal441