[qubes-users] Qubes without futzing
On Fri, Dec 28, 2018 at 08:58:37PM -0800, John Smiley wrote: I researched far and wide and decided to drop down a level and not aim for the very latest hardware. I ended up with a Thinkpad T480 with i7 quad core, Intel graphics, 2k display, 32GB memory, etc. And it was in sale for 70% off. Done. I love that little guy. It runs everything with nary a compant. I tried Ubuntu, Fedora, Pop!, Debian, and Manjaro. They all installed and ran without me having to do anything special. I was about to settle on Ubuntu even though they made some choices I didn’t like, but for a no fuss system, it’s hard to beat Ubuntu. Then i discovered Qubes. The rest is history. Futzing became my new way of life but I felt I was spending that time fruitfully. So far am happy with the choice. If anyone has ever run Qubes without futzing, what was the trick? Using well-supported hardware? A previous life as a Fedora admin? Voodoo incantations every morning? -- 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/20190101124442.ur3brencx4z7p3wo%40web.local. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Error when trying to add a lot of firewall rules
Ah! Thanks for pointing me at that bug. Yes, I'm running r4.0, but I am
just completely wrong about being up to date. My qubes-core-dom0 package
is only at 4.0.32-1, which is right before these fixes. It looks like I'm
having some issues syncing with the qubes-dom0-current repo, and so
hopefully once I figure that out I'll be all set.
Thanks for your help!
- Ralph
On Wed, Jan 2, 2019 at 1:28 AM David Hobach wrote:
> On 1/2/19 4:34 AM, qubes-users-list - wrote:
> > Ah! I reread the docs, and it mentions a size limit 3k/~35-39 rules.
> So I
> > suspect that I'm hitting this limit. I was getting the error right in
> that
> > range. Thank you for pointing me at that. The docs point out rightly
> that
> > I can just put rules in the vm directly, so I'll go that route.
> >
> > For those curious, I'm running a fully up to date R4
> >
> > The docs say "there is a 3 kB limit to the size of the iptables script".
> > I'm curious as to where that limit comes from if anyone happens to know.
>
> Hmm yes unman wrote that doc part...
>
> But considering Marek's statement in
> https://github.com/QubesOS/qubes-issues/issues/1570 : "This is already
> fixed for Qubes 4.0. The fix is not feasible for backport (it's
> incompatible change). The limitation is already documented."
>
> Are you running 4.0? Because if so, that is a bug and should cause #1570
> to be reopened. I cannot see the Qubes version from your post though.
>
> >
> >
> > On Tue, Jan 1, 2019 at 9:42 PM unman wrote:
> >
> >> On Tue, Jan 01, 2019 at 09:09:48PM -0500, qubes-users-list - wrote:
> >>> I'm trying to add a fair number (around 50?) firewall rules to a vm.
> I'm
> >>> reading a directory of wireguard configs and trying to create a
> specific
> >>> rule for each ip*port.
> >>>
> >>> After adding many rules, at a very consistent point, I get the
> following
> >>> error:
> >>>
> >>> $ qvm-firewall add --before 0 accept proto=udp dsthost=
> >>> dstports=
> >>> Got empty response from qubesd. See journalctl in dom0 for details.
> >>>
> >>> journalctl in dom0 says:
> >>>
> >>> unhandled exception while calling src=b'dom0'
> >> meth=b'admin.vm.firewall.Set'
> >>> dest=b'' arg=b'' len(untrusted_payload)=2417
> >>> Traceback (most recent call last):
> >>>File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line
> >> 262,
> >>> in respond
> >>> untrusted_payload=untrusted_payload)
> >>>File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in
> __iter__
> >>> yield self # This tells Task to wait for completion.
> >>>File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup
> >>> future.result()
> >>>File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
> >>> raise self._exception
> >>>File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
> >>> result = coro.send(None)
> >>>File "/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro
> >>> res = func(*args, **kw)
> >>>File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line
> 1303,
> >> in
> >>> vm_firewall_set
> >>> self.dest.firewall.save()
> >>>File "/usr/lib/python3.5/site-packages/qubes/firewall.py", line
> 588, in
> >>> save
> >>> self.vm.fire_event('firewall-changed')
> >>>File "/usr/lib/python3.5/site-packages/qubes/events.py", line 198,
> in
> >>> fire_event
> >>> pre_event=pre_event)
> >>>File "/usr/lib/python3.5/site-packages/qubes/events.py", line 166,
> in
> >>> _fire_event
> >>> effect = func(self, event, **kwargs)
> >>>File
> "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
> >>> line 79, in on_firewall_changed
> >>> self.write_iptables_qubesdb_entry(vm.netvm)
> >>>File
> "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
> >>> line 158, in write_iptables_qubesdb_entry
> >>> iptables)
> >>> qubesdb.Error: (0, 'Error')
> >>>
> >>> The rule in question does show up in qvm-firewall list, but I
> >>> think the new rule doesn't actually get applied.
> >>>
> >>> As soon as I delete enough rules to not get the error, it feels like
> the
> >>> rules are all properly applied again, but I didn't test this
> >>> comprehensively yet.
> >>>
> >>> It feels like I've hit some size limit? From the backtrace it looks
> like
> >>> the argument was an empty string: arg=b''. That seems suspect.
> >>>
> >>> Any pointers on where I could look in order to understand the issue
> >> better?
> >>>
> >>> Thanks in advance,
> >>>
> >>> Ralph
> >>>
> >>
> >> Which Qubes version are you using?
> >> How many rules are you able to apply?
> >> Have you looked at the docs?
> >> https://www.qubes-os.org/doc/firewall
> >>
> >> --
> >> 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-use
Re: [qubes-users] Error when trying to add a lot of firewall rules
On 1/2/19 4:34 AM, qubes-users-list - wrote:
Ah! I reread the docs, and it mentions a size limit 3k/~35-39 rules. So I
suspect that I'm hitting this limit. I was getting the error right in that
range. Thank you for pointing me at that. The docs point out rightly that
I can just put rules in the vm directly, so I'll go that route.
For those curious, I'm running a fully up to date R4
The docs say "there is a 3 kB limit to the size of the iptables script".
I'm curious as to where that limit comes from if anyone happens to know.
Hmm yes unman wrote that doc part...
But considering Marek's statement in
https://github.com/QubesOS/qubes-issues/issues/1570 : "This is already
fixed for Qubes 4.0. The fix is not feasible for backport (it's
incompatible change). The limitation is already documented."
Are you running 4.0? Because if so, that is a bug and should cause #1570
to be reopened. I cannot see the Qubes version from your post though.
On Tue, Jan 1, 2019 at 9:42 PM unman wrote:
On Tue, Jan 01, 2019 at 09:09:48PM -0500, qubes-users-list - wrote:
I'm trying to add a fair number (around 50?) firewall rules to a vm. I'm
reading a directory of wireguard configs and trying to create a specific
rule for each ip*port.
After adding many rules, at a very consistent point, I get the following
error:
$ qvm-firewall add --before 0 accept proto=udp dsthost=
dstports=
Got empty response from qubesd. See journalctl in dom0 for details.
journalctl in dom0 says:
unhandled exception while calling src=b'dom0'
meth=b'admin.vm.firewall.Set'
dest=b'' arg=b'' len(untrusted_payload)=2417
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line
262,
in respond
untrusted_payload=untrusted_payload)
File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__
yield self # This tells Task to wait for completion.
File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup
future.result()
File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
raise self._exception
File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
result = coro.send(None)
File "/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro
res = func(*args, **kw)
File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 1303,
in
vm_firewall_set
self.dest.firewall.save()
File "/usr/lib/python3.5/site-packages/qubes/firewall.py", line 588, in
save
self.vm.fire_event('firewall-changed')
File "/usr/lib/python3.5/site-packages/qubes/events.py", line 198, in
fire_event
pre_event=pre_event)
File "/usr/lib/python3.5/site-packages/qubes/events.py", line 166, in
_fire_event
effect = func(self, event, **kwargs)
File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
line 79, in on_firewall_changed
self.write_iptables_qubesdb_entry(vm.netvm)
File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
line 158, in write_iptables_qubesdb_entry
iptables)
qubesdb.Error: (0, 'Error')
The rule in question does show up in qvm-firewall list, but I
think the new rule doesn't actually get applied.
As soon as I delete enough rules to not get the error, it feels like the
rules are all properly applied again, but I didn't test this
comprehensively yet.
It feels like I've hit some size limit? From the backtrace it looks like
the argument was an empty string: arg=b''. That seems suspect.
Any pointers on where I could look in order to understand the issue
better?
Thanks in advance,
Ralph
Which Qubes version are you using?
How many rules are you able to apply?
Have you looked at the docs?
https://www.qubes-os.org/doc/firewall
--
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/20190102024257.s2plx7ipmkydl3dk%40thirdeyesecurity.org
.
For more options, visit https://groups.google.com/d/optout.
--
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/cfa34648-fc69-b5d4-3b04-bd13fd79b996%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [qubes-users] dom0 bell
On 12/31/18 11:17 AM, unman wrote: On Sun, Dec 30, 2018 at 10:32:16PM +0100, haaber wrote: Hi, I never understood the purpose of the loudspeaker bell in linux, but on my machine, it is particularly loud and annoying. Is there a reasonable way to deactivate it forever? Thank you (and a happy new year), Bernhard Try these: As root rmmod pcspkr, should stop it in running machine. Edit /etc/modprobe.d/blacklist, and insert a line: blacklist pcspkr That helps in dom0 terminal, but neither on dom0 login screen nor dom0 xterm. Funny. If that doesnt work, put the rmmod command in a startup script. I'd love to place it in /etc/rc.local -- but there is none! Can I create it?? Can I blacklist it somewhere else on boot (grub??) The ultimate sanction is to unplug the leads to the internal speaker from motherboard. Yes. That would be a joyful step, too. I am afraid if I have to cut the red or the blue cable first, to avoid detonantion :)) Let us try startup scripts first ... Bernhard -- 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/ebec7082-ba4a-7def-4a04-be11aa65fea8%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: dom0 update: sys-whonix: command failed with code: 1
Same thing here...no answers/solutions but your not alone! -- 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/ad07bc93-6e3c-4626-87a8-300474bd9c6c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Error when trying to add a lot of firewall rules
Ah! I reread the docs, and it mentions a size limit 3k/~35-39 rules. So I
suspect that I'm hitting this limit. I was getting the error right in that
range. Thank you for pointing me at that. The docs point out rightly that
I can just put rules in the vm directly, so I'll go that route.
For those curious, I'm running a fully up to date R4
The docs say "there is a 3 kB limit to the size of the iptables script".
I'm curious as to where that limit comes from if anyone happens to know.
Cheers,
Ralph
On Tue, Jan 1, 2019 at 9:42 PM unman wrote:
> On Tue, Jan 01, 2019 at 09:09:48PM -0500, qubes-users-list - wrote:
> > I'm trying to add a fair number (around 50?) firewall rules to a vm. I'm
> > reading a directory of wireguard configs and trying to create a specific
> > rule for each ip*port.
> >
> > After adding many rules, at a very consistent point, I get the following
> > error:
> >
> > $ qvm-firewall add --before 0 accept proto=udp dsthost=
> > dstports=
> > Got empty response from qubesd. See journalctl in dom0 for details.
> >
> > journalctl in dom0 says:
> >
> > unhandled exception while calling src=b'dom0'
> meth=b'admin.vm.firewall.Set'
> > dest=b'' arg=b'' len(untrusted_payload)=2417
> > Traceback (most recent call last):
> > File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line
> 262,
> > in respond
> > untrusted_payload=untrusted_payload)
> > File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__
> > yield self # This tells Task to wait for completion.
> > File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup
> > future.result()
> > File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
> > raise self._exception
> > File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
> > result = coro.send(None)
> > File "/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro
> > res = func(*args, **kw)
> > File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 1303,
> in
> > vm_firewall_set
> > self.dest.firewall.save()
> > File "/usr/lib/python3.5/site-packages/qubes/firewall.py", line 588, in
> > save
> > self.vm.fire_event('firewall-changed')
> > File "/usr/lib/python3.5/site-packages/qubes/events.py", line 198, in
> > fire_event
> > pre_event=pre_event)
> > File "/usr/lib/python3.5/site-packages/qubes/events.py", line 166, in
> > _fire_event
> > effect = func(self, event, **kwargs)
> > File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
> > line 79, in on_firewall_changed
> > self.write_iptables_qubesdb_entry(vm.netvm)
> > File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
> > line 158, in write_iptables_qubesdb_entry
> > iptables)
> > qubesdb.Error: (0, 'Error')
> >
> > The rule in question does show up in qvm-firewall list, but I
> > think the new rule doesn't actually get applied.
> >
> > As soon as I delete enough rules to not get the error, it feels like the
> > rules are all properly applied again, but I didn't test this
> > comprehensively yet.
> >
> > It feels like I've hit some size limit? From the backtrace it looks like
> > the argument was an empty string: arg=b''. That seems suspect.
> >
> > Any pointers on where I could look in order to understand the issue
> better?
> >
> > Thanks in advance,
> >
> > Ralph
> >
>
> Which Qubes version are you using?
> How many rules are you able to apply?
> Have you looked at the docs?
> https://www.qubes-os.org/doc/firewall
>
> --
> 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/20190102024257.s2plx7ipmkydl3dk%40thirdeyesecurity.org
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CAMVV%3Dfwe3dafA%3DCe3avc%2BJaZtA%2BJgJO4QaDfObVADkswk%2BxyXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Ubuntu templates
On Monday, December 31, 2018 at 7:11:21 PM UTC-7, unman wrote: > On Mon, Dec 31, 2018 at 10:35:31AM -0800, seshu wrote: > > On Wednesday, December 26, 2018 at 3:39:55 AM UTC-7, unman wrote: > > > For any one who wants to try out Xenial or Bionic, I've put some updated > > > templates for 4.0 online, including a bionic+desktop version. > > > They are pretty vanilla, except I have stopped the automatic search for > > > updates. The templates are signed with my key. > > > > > > If you use Ubuntu in Qubes I provide package repositories at > > > https://qubes.3isec.org for convenience. Full details on that page. > > > > > > As you may know Qubes doesn't provide official pre-built Templates for > > > Ubuntu, because of licensing concerns - details at > > > www.qubes-os.org/doc/templates/ubuntu > > > > > > To use my templates or packages, you will, of course, have to trust me > > > (and my key). If you're not happy doing this, then build the templates > > > and packages yourself using Qubes Builder. > > > It is simple to build templates using Qubes Builder, but some > > > people find it daunting, or don't have time. > > > If you want to do it, follow the instructions for building but select > > > "builder-debian" plugin and the Ubuntu distribution you want. If you > > > need help just ask. > > > > > > unman > > > > Hi, I'm new to Qubes and am interested in trying the ubuntu template. But, > > I"m confused on how to use the template you created? I went to 3isec.org > > site and the instructions are confusing. I see the key you have there, but > > the pgp.mit.edu server doesn't seem to be responding when I request keys. > > And then I'm not sure what to do with the rpm file for the template? > > > > Sorry to ask dumb questions, but thanks also for putting this together. > > thanks! > > > > No need to apologise. Everyone starts from somewhere. > > If you are connecting via Tor then pgp.mit.edu will often be > unresponsive. You should be able to find the key elsewhere, on other > keyservers (like keys.gnupg.net), and be able to check fingerprint > against github, or postings to this list. > Download the package in a qube. Use a Fedora based qube and you can > verify the package is signed by me, using 'rpm -K' or 'rpm -qpi' > > Once you are happy, (and have decided to trust me), you need to transfer > the package in to dom0. > Have a look at www.qubes-os.org/doc/copy-from-dom0/ for help with this. > > Once you have the package in dom0 you can install it with 'dnf install' > That will create a template, and you should be able to create qubes as > you will. > > unman Thanks! that worked really well! -- 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/816f267a-b328-48fd-b91a-853c15382512%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Error when trying to add a lot of firewall rules
On Tue, Jan 01, 2019 at 09:09:48PM -0500, qubes-users-list - wrote:
> I'm trying to add a fair number (around 50?) firewall rules to a vm. I'm
> reading a directory of wireguard configs and trying to create a specific
> rule for each ip*port.
>
> After adding many rules, at a very consistent point, I get the following
> error:
>
> $ qvm-firewall add --before 0 accept proto=udp dsthost=
> dstports=
> Got empty response from qubesd. See journalctl in dom0 for details.
>
> journalctl in dom0 says:
>
> unhandled exception while calling src=b'dom0' meth=b'admin.vm.firewall.Set'
> dest=b'' arg=b'' len(untrusted_payload)=2417
> Traceback (most recent call last):
> File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 262,
> in respond
> untrusted_payload=untrusted_payload)
> File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__
> yield self # This tells Task to wait for completion.
> File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup
> future.result()
> File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
> raise self._exception
> File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
> result = coro.send(None)
> File "/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro
> res = func(*args, **kw)
> File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 1303, in
> vm_firewall_set
> self.dest.firewall.save()
> File "/usr/lib/python3.5/site-packages/qubes/firewall.py", line 588, in
> save
> self.vm.fire_event('firewall-changed')
> File "/usr/lib/python3.5/site-packages/qubes/events.py", line 198, in
> fire_event
> pre_event=pre_event)
> File "/usr/lib/python3.5/site-packages/qubes/events.py", line 166, in
> _fire_event
> effect = func(self, event, **kwargs)
> File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
> line 79, in on_firewall_changed
> self.write_iptables_qubesdb_entry(vm.netvm)
> File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
> line 158, in write_iptables_qubesdb_entry
> iptables)
> qubesdb.Error: (0, 'Error')
>
> The rule in question does show up in qvm-firewall list, but I
> think the new rule doesn't actually get applied.
>
> As soon as I delete enough rules to not get the error, it feels like the
> rules are all properly applied again, but I didn't test this
> comprehensively yet.
>
> It feels like I've hit some size limit? From the backtrace it looks like
> the argument was an empty string: arg=b''. That seems suspect.
>
> Any pointers on where I could look in order to understand the issue better?
>
> Thanks in advance,
>
> Ralph
>
Which Qubes version are you using?
How many rules are you able to apply?
Have you looked at the docs?
https://www.qubes-os.org/doc/firewall
--
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/20190102024257.s2plx7ipmkydl3dk%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Problem after using onedrived: Directories have quotes in name
On Tue, Jan 01, 2019 at 09:25:57PM +0100, 799 wrote: > Hello, > > I have run into a (likely) major problem trying to move data from the cloud > back into Qubes. > I have setup some AppVMs to sync data from onedrive to my Qubes machine. > AppVM1 connects to onedrive via onedrived. > AppVM2 offers storage capacity via sshfs to AppVM1 > I have now found out that all directories which have space in its filename > have been saved 'FIRSTPART SECONDPART" on the drive. > Unfortunetly I am unable to cd to those directories in the AppVM2. > > Do you have any idea how I can rename them? > > Stupid me, I have deleted all data from onedrive (including) the trash as I > thought data has been transmitted savely, which it did but I havend tried > to cd into the directories which have a ' in its name :-/ > You should be able to escape the space, or use quotes: cd "FIRSTPART SECONDPART" or cd FIRSTPART\ SECONDPART You can rename them like this: rename 's/ /_/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 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/20190102021715.mmtxug5h4kx6is37%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Error when trying to add a lot of firewall rules
I'm trying to add a fair number (around 50?) firewall rules to a vm. I'm
reading a directory of wireguard configs and trying to create a specific
rule for each ip*port.
After adding many rules, at a very consistent point, I get the following
error:
$ qvm-firewall add --before 0 accept proto=udp dsthost=
dstports=
Got empty response from qubesd. See journalctl in dom0 for details.
journalctl in dom0 says:
unhandled exception while calling src=b'dom0' meth=b'admin.vm.firewall.Set'
dest=b'' arg=b'' len(untrusted_payload)=2417
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 262,
in respond
untrusted_payload=untrusted_payload)
File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__
yield self # This tells Task to wait for completion.
File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup
future.result()
File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
raise self._exception
File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
result = coro.send(None)
File "/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro
res = func(*args, **kw)
File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 1303, in
vm_firewall_set
self.dest.firewall.save()
File "/usr/lib/python3.5/site-packages/qubes/firewall.py", line 588, in
save
self.vm.fire_event('firewall-changed')
File "/usr/lib/python3.5/site-packages/qubes/events.py", line 198, in
fire_event
pre_event=pre_event)
File "/usr/lib/python3.5/site-packages/qubes/events.py", line 166, in
_fire_event
effect = func(self, event, **kwargs)
File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
line 79, in on_firewall_changed
self.write_iptables_qubesdb_entry(vm.netvm)
File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
line 158, in write_iptables_qubesdb_entry
iptables)
qubesdb.Error: (0, 'Error')
The rule in question does show up in qvm-firewall list, but I
think the new rule doesn't actually get applied.
As soon as I delete enough rules to not get the error, it feels like the
rules are all properly applied again, but I didn't test this
comprehensively yet.
It feels like I've hit some size limit? From the backtrace it looks like
the argument was an empty string: arg=b''. That seems suspect.
Any pointers on where I could look in order to understand the issue better?
Thanks in advance,
Ralph
--
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/CAMVV%3Dfz_7U-GgCFP9_605PCsyVR0cjsO2viWT8_K%3DzwQD-SwKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] dom0 update: sys-whonix: command failed with code: 1
Hi, during dom0 update I get following output: $ sudo qubes-dom0-update Using sys-whonix as UpdateVM to download updates fro dom0; this may take some time... sys-whonix: command failed with code: 1 No new updates available Qubes OS Repository for Dom0 23 MB/s | 52 kB The update than goes as normal. What does that mean and is there any action needed from my side? -- 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/LVAXE7Y--3-1%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes HCL FUJITSU CELSIUS H730
Qubes 4.0 running on the attached machine. Currently I am using some sort of dual boot. Trying to integrate the OEM Windows as a HVM. A qubes-user was already doing this: https://mbrasile.com/cms/index.php/windows-7-oem-on-qubes.html Information seems to be valid for Qubes 3.2 but some essential points are missing which can be updated from https://forums.mydigitallife.net/threads/working-bios-mod-for-ws2008-in-xen-hvm.4437/#post-350284 -- 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/AM0PR04MB590621E2E36C66F18DBBB4B8D2B30%40AM0PR04MB5906.eurprd04.prod.outlook.com. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-FUJITSU-CELSIUS_H730-20190101-225313.yml Description: Qubes-HCL-FUJITSU-CELSIUS_H730-20190101-225313.yml
[qubes-users] Qubes 4.0 UEFI Installation not recognizing
Hi all, I have a new PC and I want to setup Qubes with UEFI however after the install with UEFI the HDD isn't detected. If I change to legacy/UEFI the HDD shows I have seen the article which says to edit the boot loader file however there never seems to be that file on any USB I make. -- 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/f88afdfd-9b36-4900-89c8-328123cdf3c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?
On 01/01/2019 02:37 PM, gone wrote: Hello, 1st of all, I want to thank all the developers and supporters for that great stuff called Qubes OS. My first question here after some hard time of setting up version 4.0, updating it step by step and studying is the following: I have a debian-9 template running and for some application to get installed on it I need Python with Version >= 3.6 as a prerequisite. Since the preinstalled versions in debian-9 are 2.7 and 3.5 I attempted to install version 3.6.4 from source as described at https://www.rosehosting.com/blog/how-to-install-python-3-6-4-on-debian-9/ in order not to run into problems with incompatibilities when switching to another repo. Installing the build tools with "sudo apt-get install -y ..." worked fine but the next step, downloading the source file, with "wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz"; brings "... failed: Temporary failure in name resolution. wget: unable to resolve host address ‘www.python.org’ " As I am neither an expert nor an experienced from-source-installer I need some help and hope to get it here. Thanks very much in advance and all the best for 2019. Installing from Debian testing is much easier and it has Python 3.7. Just set the default release as in the following link, then add a line for "testing" in your /etc/apt/sources.list (and then 'apt update'): https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version -- 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 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/1b441a34-6082-32e3-95ad-8b8913199ac0%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Problem after using onedrived: Directories have quotes in name
Hello, I have run into a (likely) major problem trying to move data from the cloud back into Qubes. I have setup some AppVMs to sync data from onedrive to my Qubes machine. AppVM1 connects to onedrive via onedrived. AppVM2 offers storage capacity via sshfs to AppVM1 I have now found out that all directories which have space in its filename have been saved 'FIRSTPART SECONDPART" on the drive. Unfortunetly I am unable to cd to those directories in the AppVM2. Do you have any idea how I can rename them? Stupid me, I have deleted all data from onedrive (including) the trash as I thought data has been transmitted savely, which it did but I havend tried to cd into the directories which have a ' in its name :-/ - O -- 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/CAJ3yz2uTqHZR-dPmjiXWnmuyoQ1KLUxuDd4XRZquo%3D7wtnqScw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?
Hello, 1st of all, I want to thank all the developers and supporters for that great stuff called Qubes OS. My first question here after some hard time of setting up version 4.0, updating it step by step and studying is the following: I have a debian-9 template running and for some application to get installed on it I need Python with Version >= 3.6 as a prerequisite. Since the preinstalled versions in debian-9 are 2.7 and 3.5 I attempted to install version 3.6.4 from source as described at https://www.rosehosting.com/blog/how-to-install-python-3-6-4-on-debian-9/ in order not to run into problems with incompatibilities when switching to another repo. Installing the build tools with "sudo apt-get install -y ..." worked fine but the next step, downloading the source file, with "wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz"; brings "... failed: Temporary failure in name resolution. wget: unable to resolve host address ‘www.python.org’ " As I am neither an expert nor an experienced from-source-installer I need some help and hope to get it here. Thanks very much in advance and all the best for 2019. -- 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/c66d759d-5955-bcec-22e0-37af00a7fd08%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Cannot open terminal window in debian templates: sudden XDestroyWindow?
For future reference: - to clarify, we are talking about the Gnome terminal that cant be started from the 'qubes start menu'. - The gnome terminal *can* be started by starting UXTerm > sudo gnome-terminal. - When starting gnome terminal from the qubes start menu in a particalar qube, the syslog of that qube shows this: Dec 31 18:50:43 localhost qubes.StartApp+org.gnome.Terminal-dom0: Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached Dec 31 18:50:51 localhost systemd[1]: Started Session c8 of user user. Dec 31 18:50:52 localhost qrexec-agent[510]: eintr Dec 31 18:51:17 localhost qubes.StartApp+org.gnome.Terminal-dom0: Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached Dec 31 18:51:43 localhost dbus-daemon[743]: Failed to activate service 'org.gnome.Terminal': timed out Solution: the locale was not set properly.Fixed with "dpkg-reconfigure locales". qtpie: > Hi all, > > Since my last round of debian updates a few days agop I did I can no > longer open the > default terminals in any Debian 9 qubes (Called 'Terminal' or 'Run > Terminal' in the qubes menu), and 'GNU EMACS 23 (Terminal)'. I use the > standard Debian 9 template with no notable modifications amd no recent > changes except for the updates. > > - The issue applies to an existing debian template, a clone of that one, > a fresh one, and the TemplateVM equally. > - Other application windows than Terminal open fine including XTerm and > UXTerm so I do have a terminal. > - Whonix and Fedora qubes are fine. > - The guid log is printed below, the qrexec log only shows 'eintr' once. > > I hope somebody has a fix or a suggestion. > > > > Icon size: 128x128 > Created 0x5e3(0x61) parent 0x0(0x27e) ovr=1 x/y -1/-1 w/h 1/1 > set title for window 0x5e3 > Created 0x5e4(0xa1) parent 0x0(0x27e) ovr=0 x/y 10/10 w/h 10/10 > set WM_NORMAL_HINTS for window 0x5e4 to min=0/0, max=0/0, base=0/0, > inc=0/0 (flags 0x0) > set title for window 0x5e4 > Created 0x5e5(0x81) parent 0x0(0x27e) ovr=0 x/y 10/10 w/h 10/10 > set WM_NORMAL_HINTS for window 0x5e5 to min=0/0, max=0/0, base=0/0, > inc=0/0 (flags 0x0) > set title for window 0x5e5 > set class hint for window 0x5e5 to > (NAME-OF-MY-DEBIAN-QUBE:Gnome-settings-daemon, > NAME-OF-MY-DEBIAN-QUBE:gnome-settings-daemon) > set class hint for window 0x5e4 to > (NAME-OF-MY-DEBIAN-QUBE:Nm-applet, NAME-OF-MY-DEBIAN-QUBE:nm-applet) > Created 0x5e6(0xa3) parent 0x0(0x27e) ovr=0 x/y 0/0 w/h 1/1 > set WM_NORMAL_HINTS for window 0x5e6 to min=0/0, max=0/0, base=0/0, > inc=0/0 (flags 0x0) > set title for window 0x5e6 > set class hint for window 0x5e6 to > (NAME-OF-MY-DEBIAN-QUBE:Nm-applet, NAME-OF-MY-DEBIAN-QUBE:nm-applet) > set title for window 0x5e4 > set title for window 0x5e4 > docking window 0x5e6 > handle_configure_from_vm, local 0x5e6 remote 0xa3, 32/32, was > 1/1, ovr=0, xy 0/0, was 0/0 > process_xevent_reparent(synth 0) local 0x5e6 remote 0xa3, local > parent 0x1400415, frame window 0x1400415 > _XEMBED message 0 > fix_docked_xy(from process_xevent_xembed), calculated xy 0/0, was 0/0 > process_xevent_configure(synth 0) local 0x5e6 remote 0xa3, > 24/24, was 1/1, xy 0/0 was 0/0 > translated to -8307/- > fix_docked_xy(from process_xevent_configure), calculated xy 0/0, was 0/0 > fix_docked_xy(from process_xevent_mapnotify), calculated xy 0/0, was 0/0 > MSG_MFNDUMP for 0x5e6(0xa3): 32x32, num_mfn 0x2 off 0x498 > handle_configure_from_vm, local 0x5e6 remote 0xa3, 1/1, was > 24/24, ovr=0, xy 0/0, was 0/0 > MSG_MFNDUMP for 0x5e6(0xa3): 1x1, num_mfn 0x1 off 0x6e8 > handle_configure_from_vm, local 0x5e6 remote 0xa3, 24/24, was > 24/24, ovr=0, xy 0/0, was 0/0 > MSG_MFNDUMP for 0x5e6(0xa3): 24x24, num_mfn 0x1 off 0x498 > set title for window 0x5e6 > MSG_MFNDUMP for 0x5e6(0xa3): 24x24, num_mfn 0x1 off 0x498 > shmimage for 0x5e6(remote 0xa3), x: 0, y: 0, w: 24, h: 24 > do_shm_update for 0x5e6(remote 0xa3), after border calc: x=0, > y=0, w=24, h=24 > set WM_NORMAL_HINTS for window 0x5e6 to min=16/16, max=0/0, > base=0/0, inc=0/0 (flags 0x110) > shmimage for 0x5e6(remote 0xa3), x: 0, y: 0, w: 24, h: 24 > do_shm_update for 0x5e6(remote 0xa3), after border calc: x=0, > y=0, w=24, h=24 > do_shm_update for 0x5e6(remote 0xa3), after border calc: x=0, > y=0, w=24, h=24 > Created 0x5ee(0xa8) parent 0x0(0x27e) ovr=1 x/y -1/-1 w/h 1/1 > shmimage for 0x5e6(remote 0xa3), x: 0, y: 0, w: 24, h: 24 > do_shm_update for 0x5e6(remote 0xa3), after border calc: x=0, > y=0, w=24, h=24 > XDestroyWindow 0x5e6 > cannot lookup 0x5e6 in wid2windowdata > cannot lookup 0x5e6 in wid2windowdata > c
[qubes-users] Re: How risky is GPU pass-through?
> I don't need a core sample of the moon to know that it isn't made of green > cheese. Doesn't matter what the videos showed. There are lots of videos > that "prove" and impossible claim. If you want to believe that, it's > completely up to you. > > VMs have longer code paths than native. That alone would cause a perf hit. > Then there is the noisy neighbor problem and the fact that dom0 has to cycle > steal. Anyone with a lick of common sense would see the impossibility of > such a claim. You are correct their are some wacky videos out on the Internet. I wouldn't trust these videos if they didn't come from reliable sources, Level1techs are legit. I will assume by longer code paths you are referring to the execution times. This is true however the path is roughly only a 5% longer to execute time penalty yielding 95% of the bare metal performance. Red Hat provides most of the speed boost with their virtio drivers. You can learn more here, https://docs.fedoraproject.org/en-US/quick-docs/creating-windows-virtual-machines-using-virtio-drivers/index.html When we believe strongly about something we tend to have tunnel vision and can't see outside the box. I can only present that it works, I can not open your mind up to see outside the box nor do I want too. I respect your opinion and will hope you can do the same. Anyway, this will be my last response unless I have something new to share. I freely give you the last word if you need it. I hope you and family and everyone on this group have a very Happy New Year! Peace! -- 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/424bdaba-7989-4251-a881-39c555bfc8e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
