Re: [qubes-users] Updating to whonix-14. Error: "ImportError: No module named qubesadmin.exc"

2018-12-19 Thread 'awokd' via qubes-users




jeppewr...@gmail.com:

onsdag den 19. december 2018 kl. 06.05.57 UTC+1 skrev awokd:

jeppewr...@gmail.com:

Hi all,

I'm quite new to Qubes and Linux in general yet I have manged to run Qubes OS 
as my main desktop for several weeks. At the moment I'm fiddling with 
networking, more specifically I'm trying to get whonix-14 working, as Qubes 
comes with an outdated version(!?).

First I removed all traces of the old outdated Whonix (including 
qubes-core-admin-addon-whonix.noarch) on my system. Then I ran "sudo qubesctl 
state.sls qvm.whonix-ws-dvm" according to the documentation: 
https://www.whonix.org/wiki/Qubes/Install

After getting "bash: qubesctl: command not found" i reinstalled 
"qubes-core-admin-addon-whonix.noarch" with no effect. After that I tried searhing dom0 repo for 
salt and found "qubes-mgmt-salt.noarch" witch i also installed, it seems to help the first problem, 
but qubesctl seems broken. When running the command i get this in return:

File "/usr/bin/qubescl", line 11, in 
   import qubessalt
File "/usr/bin/python2.7/site/packages/qubessalt/__init__.py", line 10, in 

   import qubesadmin.exc
ImportError: No module named qubesadmin.exc

How do i fix this and get whonix-14 installed properly? Thanks!


I'm wondering if removing qubes-core-admin-addon-whonix.noarch broke
some other packages accidentally. Might be quickest to backup your
AppVMs, reinstall, restore, and try again? You might want to manually
install the newer Whonix templates (ws & gw) first, then try that "sudo
qubesctl state.sls qvm.whonix-ws-dvm" command again.


Thank you for your answer! I'll try and perform the operation later today. Just 
to clarify, what do you exactly mean by installing whonix manually? There are 
no whonix templates in dom0 repo if that's what you are thinking about?

You're right, the templates are not in the dom0 repo, but they are in 
qubes-templates-community. So to install one from there, you could:
sudo qubes-dom0-update --enablerepo=qubes-templates-community 
qubes-template-whonix-ws-14 (or -gw-14).


--
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/953cd470-e11d-87a3-6439-e8e9870c3923%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Updates Proxy questions and possible concern

2018-12-19 Thread unman
On Wed, Dec 19, 2018 at 11:06:25PM +, mossy wrote:
> Hello all,
> 
> I was looking to see if I could update an offline standalone VM, by
> appending a line to `etc/qubes-rpc/policy/qubes.UpdatesProxy` and I now
> have some questions.
> 
> First, I noticed the lines:
> 
> ~~~
> # Default rule for all TemplateVMs - direct the connection to sys-net
> $type:TemplateVM $default allow,target=sys-net
> ~~~
> 
> Q1) Is this correct?  Shouldn't updates be directed to sys-firewall
> instead of sys-net?  Are all of our templates exposed to (untrusted)
> sys-net?
> 
> Hopefully I am wrong about this, but either way I'd appreciate if
> someone could explain...
> 
> Q2) If I want to update an offline standalone VM called `OfflineSA`,
> what would be the proper syntax in
> `etc/qubes-rpc/policy/qubes.UpdatesProxy`?  I have tried each of the
> following without success:
> 
> OfflineSA $default allow,target=sys-net
> OfflineSA $default allow,target=sys-firewall
> OfflineSA allow,target=sys-net
> OfflineSA allow,target=sys-firewall
> $type:StandaloneVM $default allow,target=sys-net
> $type:StandaloneVM $default allow,target=sys-firewall
> 
> Q3) do I need to restart my whole qubes system for any new
> `etc/qubes-rpc/policy/qubes.UpdatesProxy` rules to come into effect?
> 
> Q4) can update proxies perhaps only be set via some $tag or $type?
> 
> Thank you!
> 
> -m0ssy

Q1. Yes, the default is to use sys-net. You can change this if you wish.
(I do)
The update proxy has always been set to sys-net by default.
The proxy used to filter traffic, but no longer does so. Again, I change
this behaviour.

Q2.  OfflineSA $default allow,target=sys-net
should work: the syntax is right. (You do have proxy configured in
OfflineSA?)

Q3. No - changes in those rules come in to play straight away.

Q4. No, they can be set on an individual basis.

-- 
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/20181220003724.hpjocaucn7eh7gkd%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Fed-28 update error

2018-12-19 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/19/18 4:34 AM, qubes-...@tutanota.com wrote:
> Hi, I updated the dom0 and after I tried to update the Fed-28 template. I get 
> following error:
> 
> [user@fedora-28 ~]$ sudo dnf update
> Last metadata expiration check: 0:27:37 ago on Wed 19 Dec 2018 11:04:23 AM 
> CET.
> Dependencies resolved.
> 
> Problem 1: cannot install the best update candidate for package 
> hplip-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-3.18.6-11.fc28.x86_64
> Problem 2: cannot install the best update candidate for package 
> hplip-libs-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-libs-3.18.6-11.fc28.x86_64
> Problem 3: cannot install the best update candidate for package 
> libsane-hpaio-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> libsane-hpaio-3.18.6-11.fc28.x86_64
> Problem 4: package hplip-libs-3.18.6-10.fc28.x86_64 requires 
> hplip-common(x86-64) = 3.18.6-10.fc28, but none of the providers can be 
> installed
>   - cannot install both hplip-common-3.18.6-11.fc28.x86_64 and 
> hplip-common-3.18.6-10.fc28.x86_64
>   - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
>   - cannot install the best update candidate for package 
> hplip-common-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-libs-3.18.6-11.fc28.x86_64
> 
> Package  Arch  VersionRepository  Size
> 
> Skipping packages with conflicts:
> (add '--best --allowerasing' to command line to force their upgrade):
> hplip-common x86_643.18.6-11.fc28 updates110 k
> Skipping packages with broken dependencies:
> hplipx86_643.18.6-11.fc28 updates 16 M
> hplip-libs   x86_643.18.6-11.fc28 updates204 k
> libsane-hpaiox86_643.18.6-11.fc28 updates127 k
> 
> Transaction Summary
> 
> Skip  4 Packages
> 
> Nothing to do.
> Complete!
> 
> ***
> 
> When doing the --best --allowerasing I get this:
> 
> [user@fedora-28 ~]$ sudo dnf --best --allowerasing update
> Last metadata expiration check: 0:28:55 ago on Wed 19 Dec 2018 11:04:23 AM 
> CET.
> Error:
> Problem 1: cannot install the best update candidate for package 
> libsane-hpaio-3.18.6-10.fc28.x86_64
>   - problem with installed package libsane-hpaio-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> libsane-hpaio-3.18.6-11.fc28.x86_64
> Problem 2: cannot install the best update candidate for package 
> hplip-libs-3.18.6-10.fc28.x86_64
>   - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-libs-3.18.6-11.fc28.x86_64
> Problem 3: cannot install the best update candidate for package 
> hplip-3.18.6-10.fc28.x86_64
>   - problem with installed package hplip-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-3.18.6-11.fc28.x86_64
> 
> *
> 
> Any help appreciated. 
> Thank you!
> 

It's an upstream Fedora issue. For more info, see:

https://github.com/QubesOS/qubes-issues/issues/4629

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwa1q4ACgkQ203TvDlQ
MDAJBQ//elkdQlan7qFyKFzj2yV/WNAlpvHxkP6GGX3CUBNlWTe7snFKZjAZgZvy
wJAorPxP0wngEdBGc9VVeQ1OYBb/DZQ6akBTtNYYmAxC+bDfS37RyIKpvFx7e22w
yrj0+0iS0T80HtrvhGfAAvBy7jro8oHiFi2u+1MDwytCVqsk2+ZeFaFaOYpDH9Zd
b5U2QpZrEdF2vckK/pBxQLWfOWgX/FildH1P7VGwKtatHArODJ4qb8GjlzswZCxk
0RDy/FCD2s7vDe3wn46zZSCBHty5XRZO2jkfMbc/pbNeie9Il87JxCNdKXcJ4bci
ENAolPWwx/xqs3Tp/kAc/KdQHC/PF0GlozmlesdFrlb8toNODnZAQ6BPitMHM5hA
ZPdzyePCcHPRvsHYAToEnLTJBvT7UsYIDuphQNCaUxfoTonBywIEeSf5jwQ2ZRiE
3CG7vkdPFDGWDMBIIr/k4J4Cg8ESaWmmaRA83LWTtGWK0h9e+2wvjA9xuu2rx9a4
CiMdttPrsKW+ub5JCl6UHq77jswMMS7JlAFQkboce75TtxATQavRDUD/Wjjweed/
wT14IFbf8qC2KPs/h8Wbhffm85TVOxQmxuWLEUobyvfhCjzGIuAtlsw2eH3uuLVT
asn+R2PmZsREU/fZnrI+bCSWeOX1G9FwkF/C9rVM0fjthP43bWU=
=4aEi
-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 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/b98c8942-83f8-4045-f8f5-74a6b35b3b2e%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Updates Proxy questions and possible concern

2018-12-19 Thread mossy
Hello all,

I was looking to see if I could update an offline standalone VM, by
appending a line to `etc/qubes-rpc/policy/qubes.UpdatesProxy` and I now
have some questions.

First, I noticed the lines:

~~~
# Default rule for all TemplateVMs - direct the connection to sys-net
$type:TemplateVM $default allow,target=sys-net
~~~

Q1) Is this correct?  Shouldn't updates be directed to sys-firewall
instead of sys-net?  Are all of our templates exposed to (untrusted)
sys-net?

Hopefully I am wrong about this, but either way I'd appreciate if
someone could explain...

Q2) If I want to update an offline standalone VM called `OfflineSA`,
what would be the proper syntax in
`etc/qubes-rpc/policy/qubes.UpdatesProxy`?  I have tried each of the
following without success:

OfflineSA $default allow,target=sys-net
OfflineSA $default allow,target=sys-firewall
OfflineSA allow,target=sys-net
OfflineSA allow,target=sys-firewall
$type:StandaloneVM $default allow,target=sys-net
$type:StandaloneVM $default allow,target=sys-firewall

Q3) do I need to restart my whole qubes system for any new
`etc/qubes-rpc/policy/qubes.UpdatesProxy` rules to come into effect?

Q4) can update proxies perhaps only be set via some $tag or $type?

Thank you!

-m0ssy

-- 
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/156da8f3-0a02-a404-3165-e8dbebe6d961%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Questions

2018-12-19 Thread John Smiley
If one were to invest in a new laptop today for Qubes use exclusively and price 
wasn't a major factor, which one(s) make the top of the list?  Assume you want 
the best security possible and are willing to invest the time to learn and 
configure Qubes/Whonix to get it.  Also assume you want something that will 
take advantage of features that are planned for near-term Qubes/Whonix release.

Are there laptops that haven't hit the market yet that would be worth waiting 
for (i.e. better than any in the list from above)?

Assume you want Anti-Evil-Maid and therefore need a TPM chip.  Does that change 
which laptops are at the top of the list and why?  Is it worth giving up the 
TPM chip if you aren't all that concerned about Evil Maid?  Pretty much every 
laptop has them these days, so a follow up question to this one would be how 
the TPM is implemented (discrete, integrated, firmware, software)?   Should the 
BIOS be set to use 1.2 or 2.0 for Qubes?

More on the BIOS - should UEFI be turned off?  Thunderbolt?  Secure boot should 
be disabled, I know.  What about power management?  Anything else (ex: if the 
laptop is Intel, ME should be disabled, correct)?

Do the keyboard and mouse/trackpad on a laptop use the USB interface?  If so, 
what is the best way to address that (buy an external PS/2 keyboard and mouse)? 
 If not, are the "safe" in the sense that only dom0 has control of them and no 
other qubes can snoop as would be the case for USB?

Are there things that can be done with a home router/firewall (such as a 
dedicated pfSense box) that improve security when using Qubes/Whonix and if so, 
what would they be?

Lot's of other questions, but this is is probably more than enough for one 
thread.

-- 
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/0a48d730-00d1-4ae4-970c-46010c6361c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: VPN for Linux Dummies

2018-12-19 Thread John Smiley
On Monday, December 17, 2018 at 12:09:48 PM UTC-8, stefanne...@gmail.com wrote:
> With Qubes 4.0 i got stuck with VPN (NordVPN)  installation because i have 
> only basic knowledge of linux. 
> 
> I found a lot of info, but most relevant are these from the Qubes Github:
> 
> https://github.com/tasket/Qubes-vpn-support
> https://github.com/tasket/qubes-tunnel
> https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service
> 
> I was successful in setting up an appvm with vpn-handler-openvpn
> I installed qubes-tunnel.git in fedora template
> I copied the region relevant but general nordvpn config files from 
> https://nordvpn.com/de/ovpn/ to /rw/config/vpn ...
> 
> But i got stuck, with a lot of questions on these different instructions. 
> What is the qubes-vpn-support folder? How to enter the login and passwort for 
> testing the connection to nordvpn? Is the vpn tunnel necessary? 
> 
> Do you have some hints? (I can`t answer tomorrow, but on wednesday.)
> 
> Thx. Stefan

I thought I'd replied to this already, but I don't see it here (maybe it was on 
Reddit).  Anyway, the use of a VPN with Tor Browser is a source of debate 
whether or not you're better off security-wise.  Whonix devotes an entire doc 
to the subject.  The gist is you're probably better off without VPN when using 
Whonix unless you have a very specific need and know what you're doing.  
https://www.whonix.org/wiki/Tunnels/Introduction

-- 
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/8775e838-cdb8-4ce8-8026-2b9a2fc10d12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes OS 4.0.1-rc2 has been released!

2018-12-19 Thread brendan . hoar
On Wednesday, December 19, 2018 at 11:19:59 AM UTC-5, Chris Laprise wrote:
> On 12/19/2018 12:42 AM, Andrew David Wong wrote:
> > Dear Qubes Community,
> > 
> > We're pleased to announce the second release candidate for Qubes 4.0.1!

> The latest update has made my VMs start noticeably faster. I'm liking it. :D

Yeah, was following that in qubes-issues. Startup was unnecessarily attempting 
to resize volumes that didn't need to be resized (and ended up not being 
resized...every boot).

B

-- 
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/7cb66d78-7a0c-42b2-9adc-b3fe465959aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Keyboard backlight color based on active qube

2018-12-19 Thread brendan . hoar
On Saturday, October 13, 2018 at 2:45:13 PM UTC-4, Brendan Hoar wrote:
> On Thursday, October 11, 2018 at 1:01:12 PM UTC-4, Marek Marczykowski-Górecki 
> wrote:
> > Hi,
> > 
> > I've published the first post on my blog:
> > https://blog.marmarek.net/blog/2018/10/11/keyboard-backlight-color-qubes.html
>
> I'm fairly certain I read about a CIA, NSA or DOD deployed OS that did 
> something very similar: the keyboard {back-,indicator-}light color was 
> changed by the OS when the compartment or security context changed. 
> Unfortunately I can't seem to track down the reference now.

Hi Marek,

I found it! DOD/NSA uses a product called SecureView for some work, built on 
XenClient/OpenXT. Not surprisingly, this particular page references Qubes: 
https://trmm.net/SecureView

Anwyay, their keyboard color-coding is called GlowView ... 
https://pbs.twimg.com/media/Dd5J-_GUwAEl8lb.jpg

Brendan

-- 
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/c41eafed-fd5f-461e-92cc-3e2c144edac7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes OS 4.0.1-rc2 has been released!

2018-12-19 Thread Chris Laprise

On 12/19/2018 12:42 AM, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

We're pleased to announce the second release candidate for Qubes 4.0.1!
Features:

  - Fixes for bugs discovered in 4.0.1-rc1
  - All 4.0 dom0 updates to date
  - Fedora 29 TemplateVM
  - Debian 9 TemplateVM
  - Whonix 14 Gateway and Workstation TemplateVMs
  - Linux kernel 4.14



The latest update has made my VMs start noticeably faster. I'm liking it. :D

--

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/cc6bd6b9-13da-632a-6086-9a66dfe99ab3%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Fed-28 update error

2018-12-19 Thread Ivan Mitev




On 12/19/18 12:34 PM, qubes-...@tutanota.com wrote:

Hi, I updated the dom0 and after I tried to update the Fed-28 template. I get 
following error:

[user@fedora-28 ~]$ sudo dnf update
Last metadata expiration check: 0:27:37 ago on Wed 19 Dec 2018 11:04:23 AM CET.
Dependencies resolved.

Problem 1: cannot install the best update candidate for package 
hplip-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-3.18.6-11.fc28.x86_64
Problem 2: cannot install the best update candidate for package 
hplip-libs-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-libs-3.18.6-11.fc28.x86_64
Problem 3: cannot install the best update candidate for package 
libsane-hpaio-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
libsane-hpaio-3.18.6-11.fc28.x86_64
Problem 4: package hplip-libs-3.18.6-10.fc28.x86_64 requires 
hplip-common(x86-64) = 3.18.6-10.fc28, but none of the providers can be 
installed
   - cannot install both hplip-common-3.18.6-11.fc28.x86_64 and 
hplip-common-3.18.6-10.fc28.x86_64
   - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
   - cannot install the best update candidate for package 
hplip-common-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-libs-3.18.6-11.fc28.x86_64

Package  Arch  Version    Repository  Size

Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
hplip-common x86_64    3.18.6-11.fc28 updates    110 k
Skipping packages with broken dependencies:
hplip    x86_64    3.18.6-11.fc28 updates 16 M
hplip-libs   x86_64    3.18.6-11.fc28 updates    204 k
libsane-hpaio    x86_64    3.18.6-11.fc28 updates    127 k

Transaction Summary

Skip  4 Packages

Nothing to do.
Complete!

***

When doing the --best --allowerasing I get this:

[user@fedora-28 ~]$ sudo dnf --best --allowerasing update
Last metadata expiration check: 0:28:55 ago on Wed 19 Dec 2018 11:04:23 AM CET.
Error:
Problem 1: cannot install the best update candidate for package 
libsane-hpaio-3.18.6-10.fc28.x86_64
   - problem with installed package libsane-hpaio-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
libsane-hpaio-3.18.6-11.fc28.x86_64
Problem 2: cannot install the best update candidate for package 
hplip-libs-3.18.6-10.fc28.x86_64
   - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-libs-3.18.6-11.fc28.x86_64
Problem 3: cannot install the best update candidate for package 
hplip-3.18.6-10.fc28.x86_64
   - problem with installed package hplip-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-3.18.6-11.fc28.x86_64

*

Any help appreciated.
Thank you!


Try to clear dnf's cache first (`sudo dnf clean all`) and see if it helps.

If not, remove the packages (eg. `dnf remove "hplip*" libsane-hpaio`), 
update the vm, and then try to reinstall the packages you've removed. 
But clone your VM first to have a backup in case things go wrong.



--
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/d703886a-0f5c-82c2-2140-59ce5ea2c97a%40maa.bz.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: thunderbird, open link in AppVM

2018-12-19 Thread Ivan Mitev




On 12/19/18 2:57 PM, dimi wrote:

On Tuesday, December 18, 2018 at 6:32:42 PM UTC+2, dimi wrote:

Since upgrade to new Template fedora 29 in R4, clicking links does not open up 
the menu.
Email Attachments do start in dispVM.

Not sure if this link select AppVM feature was build into r4 or if i used some 
github repo.


found it, 
https://micahflee.com/2016/06/qubes-tip-opening-links-in-your-preferred-appvm/


you may find that doc interesting too:

https://github.com/Qubes-Community/Contents/blob/master/docs/common-tasks/opening-urls-in-vms.md

--
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/8901045c-a2f8-a1de-8335-6981b8e887a8%40maa.bz.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Manual update Fedora, Debian and Whonix?

2018-12-19 Thread brendan . hoar
On Monday, December 17, 2018 at 6:46:02 PM UTC-5, unman wrote:
> (There is a risk with dist-upgrade that some existing packages will
> be removed, although this should not happen within a release.)
> You can also (with caution) use 'apt autoremove' but make sure you review
> the list of what is to be removed before proceeding.
> aptitude is a decent package manager worth giving a try.

Also: 

1. Always review output of updates. Several times in the past, updates have 
caused qubes-* packages to be removed (typically in a dist-upgrade or similar, 
but sometimes in the normal course of things due to a bug). This can really gum 
up restarting the template (and associated VMs). If you notice qubes-* packages 
are removed, be sure to manually reinstall them *before* shutting down the 
template/VM!
2. Always keep clones of your templates as of several updates back, just in 
case. Due to the lack of user-controlled sorting or categorizing of 
VMs/templates, I'll use a prefix of "z-" on the just-in-case clones to sort 
them to the bottom of menus/lists.

Brendan

-- 
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/985f47bf-6056-44c2-b73d-a9f99b3ddadd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: thunderbird, open link in AppVM

2018-12-19 Thread dimi
On Tuesday, December 18, 2018 at 6:32:42 PM UTC+2, dimi wrote:
> Since upgrade to new Template fedora 29 in R4, clicking links does not open 
> up the menu. 
> Email Attachments do start in dispVM.
> 
> Not sure if this link select AppVM feature was build into r4 or if i used 
> some github repo.

found it, 
https://micahflee.com/2016/06/qubes-tip-opening-links-in-your-preferred-appvm/

-- 
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/fba98bc1-3c31-4bfb-9064-287c07cb8a44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] 2FA AEM (anti-evil-maid) fails: "All key slots full"

2018-12-19 Thread Patrik Hagara
On 12/17/18 2:38 PM, 'qubeslover' via qubes-users wrote:
> Hi,
> I am trying to configure 2FA AEM (usb stick + TOTP) on my computer. I've
> done several attempts and I've probably messed up with something somewhere.
> 
> Now when I run:
> 
> "anti-evil-maid-install -m /dev/sdb1" 
> 
> * A new ext4 filesystem is created on my usb stick.
> * I get and verify my QR code.
> * I enter the passphrase for the new LUKS key file.
> 
> but I get this output in dom0:
> 
> "anti-evil-maid-install: Adding key file to new key slot for /dev/sda2
> (UUID XXX)
> All key slots full"
> 
> Can somebody help me with this, please? As mentioned above, I've done
> many attempts to configure AEM without success. However, I've never seen
> this output earlier.

Every LUKS-encrypted block device is limited to 8 key slots total (pass
phrases and key files).

You check to see the used/free key slot count using the following
command in dom0:

$ sudo cryptsetup luksDump /dev/sda2

Replace /dev/sda2 with the actual encrypted dom0 root partition, if
you're not sure which one that is (again in dom0):

$ sudo lsblk

The partition you're looking for should be listed near the top, with its
"TYPE" being "part" and it will be immediately followed by a TYPE=crypt
block device the name of which will start with "luks-".

To free up LUKS key slots, use the luksKillSlot command (it will prompt
you to enter *any* *remaining* pass phrase, to make sure you won't lock
yourself out):

$ sudo cryptsetup luksKillSlot /dev/sda2 7

where /dev/sda2 is the partition from previous step and 7 is the last
LUKS key slot (they go from 0 to 7, for a total of 8; key slot #0 will
be the pass phrase you set during Qubes installation). If you haven't
provisioned any additional pass phrases or key files, you can safely
kill slots 1 through 7 (leaving just the slot #0).


Cheers,
Patrik


> 
> Thanks in advance for your kind attention.
> 
> -- 
> 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/4gx8cl3gdGrdkuAW8YmANM_F2IUA1r74q6NpFkl3a5fQU_5WuFRe9y_bJKu0yCOGFUvkjbqfVfkjVsN-JaiGEM31WYof4wfvAL7He88T2gQ%3D%40protonmail.com
> .
> 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/05b7ecd5-b4b9-08bf-12d7-a412cd3edc2e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Updating to whonix-14. Error: "ImportError: No module named qubesadmin.exc"

2018-12-19 Thread qubes-fan
I was stuck with the Whonix upgrade 13-14 too. The best worked to just backup 
all the data from Whonix-13 templates and make a fresh install of Whonix 14. 
Than just copy all the needed data to the W-14 AppVMs like sys-whonix, 
anon-whonix and any other AppVM created. 


Dec 19, 2018, 6:05 AM by qubes-users@googlegroups.com:

> jeppewr...@gmail.com > :
>
>> Hi all,
>>
>> I'm quite new to Qubes and Linux in general yet I have manged to run Qubes 
>> OS as my main desktop for several weeks. At the moment I'm fiddling with 
>> networking, more specifically I'm trying to get whonix-14 working, as Qubes 
>> comes with an outdated version(!?).
>>
>> First I removed all traces of the old outdated Whonix (including 
>> qubes-core-admin-addon-whonix.noarch) on my system. Then I ran "sudo 
>> qubesctl state.sls qvm.whonix-ws-dvm" according to the documentation: >> 
>> https://www.whonix.org/wiki/Qubes/Install 
>> 
>>
>> After getting "bash: qubesctl: command not found" i reinstalled 
>> "qubes-core-admin-addon-whonix.noarch" with no effect. After that I tried 
>> searhing dom0 repo for salt and found "qubes-mgmt-salt.noarch" witch i also 
>> installed, it seems to help the first problem, but qubesctl seems broken. 
>> When running the command i get this in return:
>>
>> File "/usr/bin/qubescl", line 11, in 
>>  import qubessalt
>> File "/usr/bin/python2.7/site/packages/qubessalt/__init__.py", line 10, in 
>> 
>>  import qubesadmin.exc
>> ImportError: No module named qubesadmin.exc
>>
>> How do i fix this and get whonix-14 installed properly? Thanks!
>>
> I'm wondering if removing qubes-core-admin-addon-whonix.noarch broke some 
> other packages accidentally. Might be quickest to backup your AppVMs, 
> reinstall, restore, and try again? You might want to manually install the 
> newer Whonix templates (ws & gw) first, then try that "sudo qubesctl 
> state.sls qvm.whonix-ws-dvm" command again.
>
> -- 
> 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/a3a9ab08-41e4-7add-7421-a571dc99f...@danwin1210.me
>  
> >
>  .
> 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/LU52MwR--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Fed-28 update error

2018-12-19 Thread qubes-fan
Hi, I updated the dom0 and after I tried to update the Fed-28 template. I get 
following error:

[user@fedora-28 ~]$ sudo dnf update
Last metadata expiration check: 0:27:37 ago on Wed 19 Dec 2018 11:04:23 AM CET.
Dependencies resolved.

Problem 1: cannot install the best update candidate for package 
hplip-3.18.6-10.fc28.x86_64
  - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-3.18.6-11.fc28.x86_64
Problem 2: cannot install the best update candidate for package 
hplip-libs-3.18.6-10.fc28.x86_64
  - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-libs-3.18.6-11.fc28.x86_64
Problem 3: cannot install the best update candidate for package 
libsane-hpaio-3.18.6-10.fc28.x86_64
  - nothing provides libnetsnmp.so.35()(64bit) needed by 
libsane-hpaio-3.18.6-11.fc28.x86_64
Problem 4: package hplip-libs-3.18.6-10.fc28.x86_64 requires 
hplip-common(x86-64) = 3.18.6-10.fc28, but none of the providers can be 
installed
  - cannot install both hplip-common-3.18.6-11.fc28.x86_64 and 
hplip-common-3.18.6-10.fc28.x86_64
  - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
  - cannot install the best update candidate for package 
hplip-common-3.18.6-10.fc28.x86_64
  - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-libs-3.18.6-11.fc28.x86_64

Package  Arch  Version    Repository  Size

Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
hplip-common x86_64    3.18.6-11.fc28 updates    110 k
Skipping packages with broken dependencies:
hplip    x86_64    3.18.6-11.fc28 updates 16 M
hplip-libs   x86_64    3.18.6-11.fc28 updates    204 k
libsane-hpaio    x86_64    3.18.6-11.fc28 updates    127 k

Transaction Summary

Skip  4 Packages

Nothing to do.
Complete!

***

When doing the --best --allowerasing I get this:

[user@fedora-28 ~]$ sudo dnf --best --allowerasing update
Last metadata expiration check: 0:28:55 ago on Wed 19 Dec 2018 11:04:23 AM CET.
Error:
Problem 1: cannot install the best update candidate for package 
libsane-hpaio-3.18.6-10.fc28.x86_64
  - problem with installed package libsane-hpaio-3.18.6-10.fc28.x86_64
  - nothing provides libnetsnmp.so.35()(64bit) needed by 
libsane-hpaio-3.18.6-11.fc28.x86_64
Problem 2: cannot install the best update candidate for package 
hplip-libs-3.18.6-10.fc28.x86_64
  - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
  - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-libs-3.18.6-11.fc28.x86_64
Problem 3: cannot install the best update candidate for package 
hplip-3.18.6-10.fc28.x86_64
  - problem with installed package hplip-3.18.6-10.fc28.x86_64
  - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-3.18.6-11.fc28.x86_64

*

Any help appreciated. 
Thank you!

-- 
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/LU51-R---3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Updating to whonix-14. Error: "ImportError: No module named qubesadmin.exc"

2018-12-19 Thread jeppewraae
onsdag den 19. december 2018 kl. 06.05.57 UTC+1 skrev awokd:
> jeppewr...@gmail.com:
> > Hi all,
> > 
> > I'm quite new to Qubes and Linux in general yet I have manged to run Qubes 
> > OS as my main desktop for several weeks. At the moment I'm fiddling with 
> > networking, more specifically I'm trying to get whonix-14 working, as Qubes 
> > comes with an outdated version(!?).
> > 
> > First I removed all traces of the old outdated Whonix (including 
> > qubes-core-admin-addon-whonix.noarch) on my system. Then I ran "sudo 
> > qubesctl state.sls qvm.whonix-ws-dvm" according to the documentation: 
> > https://www.whonix.org/wiki/Qubes/Install
> > 
> > After getting "bash: qubesctl: command not found" i reinstalled 
> > "qubes-core-admin-addon-whonix.noarch" with no effect. After that I tried 
> > searhing dom0 repo for salt and found "qubes-mgmt-salt.noarch" witch i also 
> > installed, it seems to help the first problem, but qubesctl seems broken. 
> > When running the command i get this in return:
> > 
> > File "/usr/bin/qubescl", line 11, in 
> >   import qubessalt
> > File "/usr/bin/python2.7/site/packages/qubessalt/__init__.py", line 10, in 
> > 
> >   import qubesadmin.exc
> > ImportError: No module named qubesadmin.exc
> > 
> > How do i fix this and get whonix-14 installed properly? Thanks!
> > 
> I'm wondering if removing qubes-core-admin-addon-whonix.noarch broke 
> some other packages accidentally. Might be quickest to backup your 
> AppVMs, reinstall, restore, and try again? You might want to manually 
> install the newer Whonix templates (ws & gw) first, then try that "sudo 
> qubesctl state.sls qvm.whonix-ws-dvm" command again.

Thank you for your answer! I'll try and perform the operation later today. Just 
to clarify, what do you exactly mean by installing whonix manually? There are 
no whonix templates in dom0 repo if that's what you are thinking about?

-- 
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/4b4ebcf0-3bca-4c89-964a-50397aa8ac6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.