[qubes-users] R4.0 rc4 Back-up Bug

2018-02-14 Thread 'sebuq' via qubes-users
Backups via the Control Panel fail with the message unable to find the 
directory. However using qvm-backup via Dom0 CLI works fine.


Is it me, or is this bug on a list to be fixed at some point in the future?

--
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/8df83f67-35c6-928b-d42b-518918a6837e%40dasamy.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start

2018-02-14 Thread David Hobach

On 02/15/2018 02:00 AM, pixel fairy wrote:

On Wednesday, February 14, 2018 at 4:58:06 PM UTC-8, pixel fairy wrote:

Fedora. just tried debian. 44.286s seconds.


Forgot the hardware.

i7-6700, 64gigs ddr4, supermicro c7z170-sq, onboard intel graphics.


Got 13s with pvh on a laptop last built in 2012 or so, i.e. your timings 
are rather odd indeed...


--
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/db5c1c2b-132f-bd76-7533-2aea051f430a%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


[qubes-users] Re: HCL - HP ProBook 6565b

2018-02-14 Thread tsdelude
Tried Qubes 4.0-rc4 
VM's won't boot, likely due to lack of IOMMU. I could not change the Kernel or 
VT mode to PV from the GUI. I didn't try via terminal.

=

Qubes Release 4.0 (R4.0)

Brand: Hewlett-Packard
Model: HP ProBook 6565b
BIOS: 68LTU Ver. F.22

Xen: 4.8.3
Kernel: 4.14.13-2

RAM: 7648 Mb

CPU: AMD A4-3310MX APU with Radeon(tm) HD Graphics
Chipset: Advanced Micro Devices, Inc. [AMD] Family 12h Processor Root Complex 
[1022:1705]
Net: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit 
Ethernet Controller (rev 06)
Broadcom Limited BCM43224 802.11a/b/g/n (rev 01)
SCSI: WDC WD2500BEKT-6 Rev: 1A01

HVM: Active
I/O MMU: Not Active
HAP/SLAT: Yes
TPM: Device present
Remapping: no

Start Failed: intenal error: libxenlight failed to create new domain 'sys-net'

-- 
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/83e757db-32d0-4b45-97e0-fa8953e2e6f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Building Centos template conflict error?

2018-02-14 Thread Tim W
On Wednesday, February 14, 2018 at 11:46:32 AM UTC-5, Frédéric Pierret 
(fepitre) wrote:
> Le mercredi 14 février 2018 06:30:37 UTC+1, Tim W a écrit :
> > On Tuesday, February 13, 2018 at 5:07:32 PM UTC-5, Frédéric Pierret 
> > (fepitre) wrote:
> > > Le mardi 13 février 2018 15:47:38 UTC+1, Tim W a écrit :
> > > > I was having issues building Centos template for 4.0 so I decided to 
> > > > first see if it would build for 3.2.
> > > > 
> > > > Doing setup script templates only.  I editing example-confg 3.2 conf 
> > > > file and removed the FC version from DISTS_VM line.
> > > > 
> > > > I built it per component and it fails on the last one 
> > > > linux-template-builder.
> > > > os
> > > > 
> > > > In the centos7-template.log it shows the following conflict error
> > > > 
> > > > file /etc/dconf/profile/user from install of 
> > > > qubes-core-vm-3.2.23-1.el7.centos.x86_64 conflicts with file from 
> > > > package dconf-0.26.0-2.el7.x86_64
> > > > 
> > > > Ultimately I want to build these for 4.0 but figured first getting it 
> > > > working for 3.2 as its suppose to work there already.
> > > 
> > > The template for CentOS in Q4 is still not completely achieved. I still 
> > > need time to fix several things.
> > 
> > But the error I am getting is for Q-3.2 not 4.0.  Its listed in my first 
> > post, 
> > 
> > I had not included the 4.0 errors as I thought it might just be a needed 
> > update of software version or module but here they are from 4.0 in case 
> > they are of any use to you.
> > 
> > Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> > (template-builder-repo)
> >Requires: python3-pillow
> > Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> > (template-builder-repo)
> >Requires: python2-numpy
> > Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> > (template-builder-repo)
> >Requires: python2-pillow
> > Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> > (template-builder-repo)
> >Requires: python3-numpy
> > 
> > Shouldn't 3.2 still be buildable ?
> > 
> > Instead in 3.2 I am getting the following during $ make 
> > linux-template-builder  :
> >  
> > file /etc/dconf/profile/user from install of 
> > qubes-core-vm-3.2.23-1.el7.centos.x86_64 conflicts with file from package 
> > dconf-0.26.0-2.el7.x86_64
> 
> Sorry I read too fastly. The errors in Q4 for the python dependencies are 
> exactly some of the reasons why it is long to do the template. Some python3 
> packages are not built for CentOS...For you problem I need to perform the 
> rebuild with the latest version of r3.2 packages. I keep you in touch.


Sounds good.  I figured that was the issue for the Q4 but Q3.2 error was the 
one that surprised me as its been a good build in the past.

Just an FYI I am building this in F23 but did bring in the correct python2.sh.  
Have had no issues building standard Q3.2 and 4.0 ISOs.

-- 
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/ab840e15-d731-433a-85dc-56aee698828c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start

2018-02-14 Thread WillyPillow
I also noticed similar slowdowns. I have no experience with rc3 (upgraded 
directly from 3.2), but your numbers seem to councide with my experience. 
Hardware is also pretty similar, namely Z170/6700K.

--WillyPillow
--
https://blog.nerde.pw/
PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154  217F 1C16 C70E E7C3 1C8
--

-- 
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/_u34bjS6AXj5CHBS0GgzGXhvql6dmV8Qa5ABa-NOi-JKjSal18usCoqxPpf01YSQp6FQ0vnvgGNIKUbKiyOrl_gjIrlgsRBW4K8iZGM7Lcc%3D%40nerde.pw.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start

2018-02-14 Thread pixel fairy
pvh. the hvm ones took even longer. looked at a couple systemd-analyze, one of 
them had 10s for dkms and 40 for qubes-update-check, even though that one only 
took 25s to boot, at least according to dom0. could whatever tells dom0 a guest 
is up have run before that?

will play with this more and get back to you.

turns out the qvm-pref debug doesnt matter in boot time. its hvm that takes 
around 40 seconds, and pvh that takes around 25.

a standalone hvm with no os installed took 16 seconds to "start"

this started happening after installing 4.0rc4 over 4.0rc3. had to qvm-prefs 
the restored vms to pvh. at first i thought it was just the performance hit 
from mitigating speculation vulnerabilities, but others were reporting better 
performance in rc4 than rc3.

-- 
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/e15ed300-e888-4cbc-99a7-5ecc82323d8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start

2018-02-14 Thread Chris Laprise

On 02/14/2018 08:00 PM, pixel fairy wrote:

On Wednesday, February 14, 2018 at 4:58:06 PM UTC-8, pixel fairy wrote:

Fedora. just tried debian. 44.286s seconds.


Forgot the hardware.

i7-6700, 64gigs ddr4, supermicro c7z170-sq, onboard intel graphics.



What virt_mode is used? Default is pvh; Try switching the mode to hvm 
(and this let you use debug mode). Then there are logs in dom0 
/var/log/qubes for each VM.


On the VM side you can try 'systemd-analyze blame' for start timings, 
also 'journalctl' and 'dmesg'.



--

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/b8ce3117-8464-c83a-ffef-4878cc3fb100%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start

2018-02-14 Thread pixel fairy
On Wednesday, February 14, 2018 at 4:58:06 PM UTC-8, pixel fairy wrote:
> Fedora. just tried debian. 44.286s seconds.

Forgot the hardware. 

i7-6700, 64gigs ddr4, supermicro c7z170-sq, onboard intel graphics.

-- 
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/7cc90ae0-f905-4f99-beef-90c3fc4dbc09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start

2018-02-14 Thread pixel fairy
Fedora. just tried debian. 44.286s seconds.

-- 
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/a025ca67-8aa1-4097-a096-372ec3e41fe3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start

2018-02-14 Thread Chris Laprise

On 02/14/2018 05:47 PM, pixel fairy wrote:

[user@dom0 ~]$ time qvm-start personal

real0m23.517s
user0m0.182s
sys 0m0.065s
[user@dom0 ~]$ time qvm-start alpha

real0m23.801s
user0m0.191s
sys 0m0.056s
[user@dom0 ~]$ time qvm-start alphax

real0m32.831s
user0m0.193s
sys 0m0.059s

starting with debug turned on takes 46 seconds. it shows a console window with

SeaBIOS
Machine UUID
Booting from ROM...
Probing EDD...

15 seconds for the console window to come up, with the first 3 lines
8 seconds later for Probing EDD to come up
23 seconds after that for the VM to start and the console window to go blank.



Is this Debian or Fedora? If the latter, can you try Fedora?

--

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/1e54cfd9-47a3-084a-7b3a-68d47b5e7bf3%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] 4.0-rc3: sys-net not getting updated template OS image?

2018-02-14 Thread Rusty Bird
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Steve Coleman:
> Here is the sys-net . I re-wraped the xml to make it a little
> more readable in email:
> 
>  
>  pool="lvm"
> revisions_to_keep="0"
> size="21474836480"
> snap_on_start="True"
> source="qubes_dom0/vm-fedora-26-net-root"
> vid="qubes_dom0/vm-sys-net-root"/>

Looks good.

> Since it is the template (fedora-26-net) itself that appears to be broken,
> would that not be what needs to be verified?

I had a hunch that somehow the wrong template might have ended up as
the source volume for sys-net's root volume, but apparently not.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJahMpEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf408P/1JnKeJDyxbbnFQZHLdphFod
ZvR6G3IAzjKm1ekqfXiCedbRXFCK35Olw+PO+r0MEVMvHH414CvcuN9Fgf0LyqHC
qtGHnPl1eaxt/i7Wt8h/GKd+9bxysE9CtV43JntSAYd4atbTiv7FMSUOPgZyanTo
ycEAPdL96LtTYUtD3jR/FOv+1OHk92mYgQrIWe/LfljEWlrGXj/+yDIHxEpZpAmW
0d600FfqRTGh/QDmb2IcZkrBCc6bR5qh7tyxwA7eq+TywMWdeyCeL7zNpmYNqRHu
tjLgUdQsCo/2OnqF5t1/HDLcTcnen1Yw7sQpl4hdb7E+tnqHyZ04NgMSuM9bERT7
MC2fPxh5d55yY44jLJpwr2pH5W0/Oj/jswHfAtJrf+uNnOJqApJmFKXd6MjU0vzi
JKDbj9L2itt6Q9uni3C7wMKPtLqqq0K/0XIflbBoRa39apHgn7QaHFG+kqmY7Its
rwF3voMUbwGohjwrEGZIh9VG7dMyqK2vAVW0KwG01fpJO7mVsNZoClAxlK6cR6C7
jwEKJszz6vQ1Xfi85o+5OJlk4EV1pUrCSzd0lqdZUQDrZxzZ8EqeRLSlfmGZ8UpL
jP1Dyc1QyY5IdMObmnnAAvf+0ehB2EsFo7jgn0pXPPiiH/7Qf8L5xB2yyEFNKW+z
70Xb+0LZHCscftb46Zsq
=wqE/
-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/20180214234612.GA2755%40mutt.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start

2018-02-14 Thread pixel fairy
[user@dom0 ~]$ time qvm-start personal

real0m23.517s
user0m0.182s
sys 0m0.065s
[user@dom0 ~]$ time qvm-start alpha

real0m23.801s
user0m0.191s
sys 0m0.056s
[user@dom0 ~]$ time qvm-start alphax

real0m32.831s
user0m0.193s
sys 0m0.059s

starting with debug turned on takes 46 seconds. it shows a console window with

SeaBIOS
Machine UUID
Booting from ROM...
Probing EDD...

15 seconds for the console window to come up, with the first 3 lines
8 seconds later for Probing EDD to come up
23 seconds after that for the VM to start and the console window to go blank.

-- 
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/a49c3481-a3c1-4147-8efe-47277079974e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] 4.0-rc3: sys-net not getting updated template OS image?

2018-02-14 Thread Steve Coleman

On 02/14/18 12:14, Rusty Bird wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Steve Coleman:

I have a strange situation where my sys-net's software template
"fedora-26-net" (variant of fedora-minimal) does not appear to be providing
updated OS images. My sys-net is the only vm using this specific image.


Assuming that sys-net is _not_ a DispVM, maybe this is still somehow
similar to https://github.com/QubesOS/qubes-issues/issues/3576 - can
you search for 'sys-net' in dom0's
/var/lib/qubes/qubes.xml and post the next (i.e. somewhere below that
line) XML '' block?



I looked at the github issue and I'm not certain of any similarity. I 
did copy another template vm to make sys-net's template, but I can not 
remember copying or renaming the sys-net vm itself.


Here is the sys-net . I re-wraped the xml to make it a 
little more readable in email:


 




  


Since it is the template (fedora-26-net) itself that appears to be 
broken, would that not be what needs to be verified? Here is the 
fedora-26-net template config:


 




  

if there is a problem there I'm just not seeing it.

thanks,

Steve


Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJahG6JXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfmwsQAIw0uxVBLbrz543iD0z6EqBn
doi1XooXsmoqfaFXvSqnJSJlVr1vhgFM+mYVzpPIOvT20AhzgYDIP1YWjU/KWO3q
DNKkpLuzJqhPfG2XTv63MGmji/Tz1vLMK6OGTDSU7THR8DgKJSfy/3bBRJP9meeq
x4BzUmTG7HVUsjbRO7AK1QO4XaCwi8sFCsnRNht4UsL0ulSeAG1gaVxR9zxSul2U
hqLW8SGk+zgMbsdY8pNjreUNmMK63r9auIAiIapoU9s13g42P7E3ujI9HX2iO8C0
PXQfmNo2U1frSycySLn5kn8Qa94uLvLTf6Xj2985EPsmicYH85PdGKwVRsa0ObLQ
/RrWrbxbximu8g8onbPnqMig5Nu56yyMD/m4CY7PDaqh/IN1cK3e9tBbO574QuHH
kkVgmzC9ojrIXDk7qH2Tp5M2P6KtSNHHQ2NXiImuxDxW6ZV47AnjIngk5Rw4bfCI
xrv1EU/Ujxa0ioosm4NkC6tPb2bqbRoHYqiEZigx4/onpV1YM+mgsHNLoopFJ3qY
QqMu9YFTJv9IY2/f6NsVLuWh0QU1csBXETr41UOZwB/AnOqolm0jrZADD+8EjnQ6
My+WUCm+WZWKz55iuFPVDxscRSWxQeMOc7msyKACk0Ej6Th1RJcc1yKt20eIw9QA
XA0EWlMJksbqJaqyVgmO
=UNib
-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/cebbb4c3-d7cc-a402-6283-c2a872b164ad%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Salt management questions

2018-02-14 Thread Johannes Graumann
On Mon, 2018-02-12 at 17:04 +0100, Johannes Graumann wrote:
> On Wed, 2018-02-07 at 15:27 +0100, Johannes Graumann wrote:
> > Gentlepeople,
> > 
> > For a while I have been managing a qubes setup using a dedicated
> > management VM and ansible via https://github.com/Rudd-O/ansible-qub
> > es
> > .
> > As auditing that code is beyond me and as salt is integral to
> > qubes,
> > I
> > was wondering whether that layout is currently possible using the
> > salt
> > management stack, in other words: can the management stack
> > (currently)
> > be used with a vm as the master to the entire system including
> > dom0?
> > 
> > Sincerely, Joh
> > 
> 
> I understand this may be IT-people-level stuff ..., but can anyone
> hint
> at whether this is already possible and or where to look?
> 
> Joh
> 

Here https://www.qubes-os.org/news/2015/12/14/mgmt-stack/, Marek
Marczykowski-Górecki sais (referring to the core rewrite back then
ongoing for 4.)):
+ Then, based on this functionality, we will be able to create a 
+ Management VM, which will allow secure, centralized management of 
+ Qubes OS installations in an organization or company. But to do it 
+ securely, we need to first finish some major rework of Qubes core 
+ management code (“core3”), which is planned for Qubes 4.0. Then it 
+ will be possible to implement Management VM in a way so that it will 
+ have no access to user data, only ability to manage configuration of 
+ (selected) VMs.
This is exactly what I want - plus limited tor/net connectivity to
track/backup my salt infrastructure in a gpg-encrypted git repo ...
Are we there yet?

Joh



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


[qubes-users] Re: Ubuntu templates

2018-02-14 Thread Bertrand Lec
Le jeudi 1 février 2018 00:56:29 UTC+1, Unman a écrit :
> I'm just pushing up some PRs to remove zesty and institute build support
> for artful (17.10).
> If you cant wait there's a ready built 3.2 template you can try at:
> http://qubes.3isec.org/Templates
> 
> unman

Thank you a lot for your work.

Do you know which qvm-* tools to install? The ones in 
http://qubes.3isec.org/3.2/ are not for artful and the Release file is missing. 
Can I use the debian ones?

Thanks a lot
Bertrand

-- 
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/bb5f4d81-4519-4486-995b-1b37e49948b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Setting up privateinternetaccess on qubes 3.2

2018-02-14 Thread velcro
Thank you Tasket\Chris...

Thanks for the education on trust/veracity/trustworthiness with Github.

You and the Qubes team are doing a good thing! I really appreciate all the 
help...

Thank you!

V

-- 
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/9a06d65d-ee00-4ec8-bd2f-20b7d30bda0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: R4 rc4 - Whonix System Time Error

2018-02-14 Thread brendan . hoar
On Wednesday, February 14, 2018 at 5:33:03 AM UTC-5, sebuq wrote:
> The virgin whonix templates issue with official Qubes R4 rc4 downloads 
> did not result in errors via whonixcheck. However after updating the 
> whonix-gw template a get the following system time error:
> 
> ERROR: Systemd Clock Check Result:
> Unexpected results by timedatectl.
> timedatectl_output_pretty:
> Local time: Wed 2018-02-14 10:25:33 UTC
> Universal time: Wed 2018-02-14 10:25:33 UTC
> RTC time: n/a
> Time zone: Etc/UTC (UTC, +)
> NTP enabled: yes
> NTP synchronized: no
> RTC in local TZ: no
> DST active: n/a
> It is generally recommended to keep the default as per Whonix Design. 
> [1] If you did not change timezone related settings, please report this 
> Whonix bug. If you know what you are doing and changed this on purpose, 
> feel free to disable this check. [2]
> 
> [1] https://www.whonix.org/wiki/Dev/Design-Shared#timezone
> [2] Create a file /etc/whonix.d/50_whonixcheck_user and add:
> whonixcheck_skip_functions+=" check_systemd_clock "

I have seen the same, but it the sys-whonix vm still manages to connect...

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/fe40c2ac-4161-4480-9211-6ad53f940685%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Win7, qvm-copy-to-vm, QubesIncoming location?

2018-02-14 Thread brendan . hoar
On Wednesday, February 14, 2018 at 3:32:18 AM UTC-5, Ivan Mitev wrote:
> On 02/13/2018 10:34 PM, Brendan Hoar wrote:
> > On Tuesday, February 13, 2018 at 2:06:59 PM UTC-5, brenda...@gmail.com 
> > wrote:
> >> On Friday, March 3, 2017 at 1:36:35 PM UTC-5, Martin L. Fällman wrote:
>  Does the issue still occur after You change the default Windows user in
>  Qubes settings? qvm-prefs -s windows default_user admin ?
> >>>
> >>> Just tried it, yep. This is strange!
> >>
> >> I am seeing the same issue with a Win7 HVM under R4.0rc4 using the qubes
> >> windows drivers. First copy seems to work from a fedora VM but no file 
> >> shows
> >> up in windows. Additional attempts to copy says it failed because the file 
> >> is
> >> already there. Happens across reboots (fedora source says file is "there" 
> >> but
> >> nothing on the drives in windows).
> > 
> > Found it (windows 7 search explicitly skips the system directory, so it's a 
> > little difficult to discover).
> > 
> > The following directory is the receiving directory:
> > 
> >C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\
> > 
> > Presumably this maps correctly for the account that qubes tools component 
> > is running under.
> > 
> > Just FYI, in case someone else runs into this.
> 
> I did run into this a few days ago...
> 
> I've just opened an issue to track those things:
> 
> https://github.com/QubesOS/qubes-issues/issues/3585

Thanks!
 
> BTW, did you manage to build QWT ?

Sadly, no - I ran out of vacation time (...and should have asked before banging 
my ahead against the issue for so long). I still have my build environment and 
Marek's response in my queue so maybe I'll look at it this weekend.

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/0f557469-41a5-4cce-98d7-1d5d110f4e7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] 4.0-rc3: sys-net not getting updated template OS image?

2018-02-14 Thread Rusty Bird
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Steve Coleman:
> I have a strange situation where my sys-net's software template
> "fedora-26-net" (variant of fedora-minimal) does not appear to be providing
> updated OS images. My sys-net is the only vm using this specific image.

Assuming that sys-net is _not_ a DispVM, maybe this is still somehow
similar to https://github.com/QubesOS/qubes-issues/issues/3576 - can
you search for 'sys-net' in dom0's
/var/lib/qubes/qubes.xml and post the next (i.e. somewhere below that
line) XML '' block?

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJahG6JXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfmwsQAIw0uxVBLbrz543iD0z6EqBn
doi1XooXsmoqfaFXvSqnJSJlVr1vhgFM+mYVzpPIOvT20AhzgYDIP1YWjU/KWO3q
DNKkpLuzJqhPfG2XTv63MGmji/Tz1vLMK6OGTDSU7THR8DgKJSfy/3bBRJP9meeq
x4BzUmTG7HVUsjbRO7AK1QO4XaCwi8sFCsnRNht4UsL0ulSeAG1gaVxR9zxSul2U
hqLW8SGk+zgMbsdY8pNjreUNmMK63r9auIAiIapoU9s13g42P7E3ujI9HX2iO8C0
PXQfmNo2U1frSycySLn5kn8Qa94uLvLTf6Xj2985EPsmicYH85PdGKwVRsa0ObLQ
/RrWrbxbximu8g8onbPnqMig5Nu56yyMD/m4CY7PDaqh/IN1cK3e9tBbO574QuHH
kkVgmzC9ojrIXDk7qH2Tp5M2P6KtSNHHQ2NXiImuxDxW6ZV47AnjIngk5Rw4bfCI
xrv1EU/Ujxa0ioosm4NkC6tPb2bqbRoHYqiEZigx4/onpV1YM+mgsHNLoopFJ3qY
QqMu9YFTJv9IY2/f6NsVLuWh0QU1csBXETr41UOZwB/AnOqolm0jrZADD+8EjnQ6
My+WUCm+WZWKz55iuFPVDxscRSWxQeMOc7msyKACk0Ej6Th1RJcc1yKt20eIw9QA
XA0EWlMJksbqJaqyVgmO
=UNib
-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/20180214171449.GA2281%40mutt.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Setting up privateinternetaccess on qubes 3.2

2018-02-14 Thread Chris Laprise

On 02/13/2018 05:23 PM, vel...@tutamail.com wrote:

Thanks Chris(and "tasket"!)took me a few tries but I managed to get it 
going, I tweaked the implementation a bit(scarey).

I was not however able to get this command going from step #3 of the Github 
guide:  sudo /usr/lib/qubes/qubes-vpn-setup --config

I doubt I did this right/well but when I went to DNSleaktest.com it showed no 
leaks.


Since you installed into a proxyVM only (not a template) you should skip 
this command anyway (per instructions).





Couple of questions:
* What security am I not getting by doing step #3?
* Is using a script from Github good? Appreciate the lead but will this be 
sanctioned by the Qubes community long term?


That depends. For one, you should be accessing github through HTTPS 
which offers some protection. As for my veracity/trustworthiness that is 
ultimately up to you, but looking at the commits you'll notice they are 
cryptographically signed by me so they can be verified in 'git'. And 
there is the pattern of my (signed) contributions accepted to Qubes and 
other projects.


I'm helping add new vpn tunnel features in Qubes itself, so you can 
think of this as most of Qubes-vpn-support being incorporated into the OS.



* How can I test the kill switch functionality?


If you mean anti-leak, you can try leak testing sites* like you 
mentioned or try monitoring traffic in an upstream vm for any packets 
sent to non-vpn addresses.


*Some more sites: https://github.com/tasket/Qubes-vpn-support/issues/1

One way you can check if the firewall script is running is if 'sudo 
iptables -L -v' shows the following rule at the top of the FORWARD section:


DROPall  --  eth0   any  anywhere  anywhere


Thanks for the feedback!


--

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/06e0b075-3336-b1f1-d1cc-cb6e40b54511%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Building Centos template conflict error?

2018-02-14 Thread fepitre
Le mercredi 14 février 2018 06:30:37 UTC+1, Tim W a écrit :
> On Tuesday, February 13, 2018 at 5:07:32 PM UTC-5, Frédéric Pierret (fepitre) 
> wrote:
> > Le mardi 13 février 2018 15:47:38 UTC+1, Tim W a écrit :
> > > I was having issues building Centos template for 4.0 so I decided to 
> > > first see if it would build for 3.2.
> > > 
> > > Doing setup script templates only.  I editing example-confg 3.2 conf file 
> > > and removed the FC version from DISTS_VM line.
> > > 
> > > I built it per component and it fails on the last one 
> > > linux-template-builder.
> > > os
> > > 
> > > In the centos7-template.log it shows the following conflict error
> > > 
> > > file /etc/dconf/profile/user from install of 
> > > qubes-core-vm-3.2.23-1.el7.centos.x86_64 conflicts with file from package 
> > > dconf-0.26.0-2.el7.x86_64
> > > 
> > > Ultimately I want to build these for 4.0 but figured first getting it 
> > > working for 3.2 as its suppose to work there already.
> > 
> > The template for CentOS in Q4 is still not completely achieved. I still 
> > need time to fix several things.
> 
> But the error I am getting is for Q-3.2 not 4.0.  Its listed in my first 
> post, 
> 
> I had not included the 4.0 errors as I thought it might just be a needed 
> update of software version or module but here they are from 4.0 in case they 
> are of any use to you.
> 
> Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> (template-builder-repo)
>Requires: python3-pillow
> Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> (template-builder-repo)
>Requires: python2-numpy
> Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> (template-builder-repo)
>Requires: python2-pillow
> Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> (template-builder-repo)
>Requires: python3-numpy
> 
> Shouldn't 3.2 still be buildable ?
> 
> Instead in 3.2 I am getting the following during $ make 
> linux-template-builder  :
>  
> file /etc/dconf/profile/user from install of 
> qubes-core-vm-3.2.23-1.el7.centos.x86_64 conflicts with file from package 
> dconf-0.26.0-2.el7.x86_64

Sorry I read too fastly. The errors in Q4 for the python dependencies are 
exactly some of the reasons why it is long to do the template. Some python3 
packages are not built for CentOS...For you problem I need to perform the 
rebuild with the latest version of r3.2 packages. I keep you in touch.

-- 
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/34bf6b9a-dc6b-4695-8ab4-24ca692dc677%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Building Centos template conflict error?

2018-02-14 Thread fepitre
Le mercredi 14 février 2018 06:30:37 UTC+1, Tim W a écrit :
> On Tuesday, February 13, 2018 at 5:07:32 PM UTC-5, Frédéric Pierret (fepitre) 
> wrote:
> > Le mardi 13 février 2018 15:47:38 UTC+1, Tim W a écrit :
> > > I was having issues building Centos template for 4.0 so I decided to 
> > > first see if it would build for 3.2.
> > > 
> > > Doing setup script templates only.  I editing example-confg 3.2 conf file 
> > > and removed the FC version from DISTS_VM line.
> > > 
> > > I built it per component and it fails on the last one 
> > > linux-template-builder.
> > > os
> > > 
> > > In the centos7-template.log it shows the following conflict error
> > > 
> > > file /etc/dconf/profile/user from install of 
> > > qubes-core-vm-3.2.23-1.el7.centos.x86_64 conflicts with file from package 
> > > dconf-0.26.0-2.el7.x86_64
> > > 
> > > Ultimately I want to build these for 4.0 but figured first getting it 
> > > working for 3.2 as its suppose to work there already.
> > 
> > The template for CentOS in Q4 is still not completely achieved. I still 
> > need time to fix several things.
> 
> But the error I am getting is for Q-3.2 not 4.0.  Its listed in my first 
> post, 
> 
> I had not included the 4.0 errors as I thought it might just be a needed 
> update of software version or module but here they are from 4.0 in case they 
> are of any use to you.
> 
> Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> (template-builder-repo)
>Requires: python3-pillow
> Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> (template-builder-repo)
>Requires: python2-numpy
> Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> (template-builder-repo)
>Requires: python2-pillow
> Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> (template-builder-repo)
>Requires: python3-numpy
> 
> Shouldn't 3.2 still be buildable ?
> 
> Instead in 3.2 I am getting the following during $ make 
> linux-template-builder  :
>  
> file /etc/dconf/profile/user from install of 
> qubes-core-vm-3.2.23-1.el7.centos.x86_64 conflicts with file from package 
> dconf-0.26.0-2.el7.x86_64

It is normal. python3-pillow and python3-numpy are not provided in the CentOS 
repositories. As it some Qubes r4.0 code has been backported into r3.2, the 
dependencies are not satisfied...this is why it takes quite some time to do the 
packaging for python3 packages for CentOS template.

-- 
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/54f24f34-53c2-4b80-bcc0-609f1848a9eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] can't install fail2ban or sshguard

2018-02-14 Thread Ivan Mitev



On 02/14/2018 05:42 PM, Matus wrote:

thank you for help. it was exactly as you said. i just installed only fail2ban 
server package and set it up and it works correctly with iptables.


you're welcome - happy to read you worked it out.

ivan

--
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/672ec1bd-0885-be82-5990-1f765b1860b7%40maa.bz.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] 4.0-rc3: sys-net not getting updated template OS image?

2018-02-14 Thread Steve Coleman

On 02/13/18 14:54, awokd wrote:

On Tue, February 13, 2018 6:32 pm, Steve Coleman wrote:

I have a strange situation where my sys-net's software template
"fedora-26-net" (variant of fedora-minimal) does not appear to be
providing updated OS images. My sys-net is the only vm using this specific
image.


Are you running low on disk space?

Not exactly sure what's going on there, but can you try to clone the
problem template and point your AppVM to the clone instead, and see if
that works?





This template is only 30% used.

As was suggested, I cloned the template to see what happened. There were 
no apparent errors when cloning.


- Before testing the template clone with an appvm I did a "dnf update" 
in each template (orig & clone). The clone got 135 updates, and the 
original said it was already up to date. Clearly cloning is not an exact 
copy mechanism.


- To check why the difference in the updates, an 'rpm -qa' verified that 
they are both now on the exact same version #'s of the updated packages 
that I checked, so the original template was not lying to me that it was 
"up to date". How the copy could be out of date is then quite puzzling.


- As for the /opt directory found in each, the clone has the invalid 
subdirectories in /opt, and the original template has the correct set of 
directories. So cloning works just the same as OS provisioning in that 
it collects the wrong data, and copies that.


- As for the planned appvm test, when using the cloned template, it 
obviously saw the wrong /opt directories which were in the cloned template.


My plan to move myself forward is to update the new clone with the right 
software packages and swap that template into sys-net, removing the bad 
template.


But, understanding how this kind of corruption happened could be 
important. Something is obviously broken with this original template, so 
I went to look for any sign of cross-linked inodes in the image files or 
directory structures, only to find that Qubes 4.0 totally changed the 
way that VM image files are stored and handled. Wow, I don't even know 
where to begin. An fsck in dom0 says everything is fine there. I have no 
clue as to what constitutes an appvm filesystem image in the new design.




Steve

--
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/f306097b-88d7-f6d9-c9ed-ddc30ebd87db%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] can't install fail2ban or sshguard

2018-02-14 Thread Matus
thank you for help. it was exactly as you said. i just installed only fail2ban 
server package and set it up and it works correctly with iptables.

-- 
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/347cd0c6-fcd7-45ff-b06b-e36ab5febcec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] can't install fail2ban or sshguard

2018-02-14 Thread Ivan Mitev



On 02/14/2018 04:39 PM, Matus wrote:

Hello,

I'm using qubes os 3.2 with official template fedora 26 minimal. I tried 
installing fail2ban or sshguard but i get following error:

dnf install fail2ban
Failed to set locale, defaulting to C
Fedora 26 - x86_64 - Updates
  10 MB/s |  20 MB 00:01
Puppet Labs PC1 Repository fedora f26 - x86_64  
 4.0 MB/s | 104 kB 00:00
Qubes OS Repository for VM (updates)
 252 kB/s |  62 kB 00:00
Last metadata expiration check: 0:00:00 ago on Wed Feb 14 15:08:25 2018.
Error:
  Problem: conflicting requests
   - package fail2ban-0.9.7-2.fc26.noarch requires fail2ban-firewalld = 
0.9.7-2.fc26, but none of the providers can be installed
   - package fail2ban-0.9.6-4.fc26.noarch requires fail2ban-firewalld = 
0.9.6-4.fc26, but none of the providers can be installed
   - package fail2ban-firewalld-0.9.7-2.fc26.noarch requires firewalld, but 
none of the providers can be installed
   - package fail2ban-firewalld-0.9.6-4.fc26.noarch requires firewalld, but 
none of the providers can be installed
   - problem with installed package qubes-core-vm-3.2.22-1.fc26.x86_64
   - package qubes-core-vm-3.2.22-1.fc26.x86_64 conflicts with firewalld 
provided by firewalld-0.4.4.5-1.fc26.noarch
   - package qubes-core-vm-3.2.20-1.fc26.x86_64 conflicts with firewalld 
provided by firewalld-0.4.4.5-1.fc26.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or 
'--skip-broken' to skip uninstallable packages)

The qubes-core-vm have conflict with firewalld. Can I resolv this issue somehow 
or I can't use fail2ban or any other similar tool?


Qubes uses plain iptables so you shouldn't mess with firewalld.
It looks like you may install only the fail2ban server part [1] ; 
otherwise you could install from source or pick the required files from 
the rpm.


https://osric.com/chris/accidental-developer/2017/08/using-fail2ban-with-iptables-instead-of-firewalld/

--
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/16d70a54-4c97-4ffa-75bc-f0fddf41baa6%40maa.bz.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] If you get 'no authenticators available' with mutt

2018-02-14 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Feb 10, 2018 at 01:33:53PM -, 'awokd' via qubes-users wrote:
> On Fri, February 9, 2018 5:32 pm, Konstantin Ryabitsev wrote:
> > If you are trying to use mutt with the default Fedora-26 template and
> > can't figure out why authenticated smtp sending is giving you a "No
> > Authenticators Available" error, you need to install cyrus-sasl-plain.
> >
> >
> > Drove me half-mad before I figured that out. Hopefully it saves you a
> > bunch of clicks (and hair).

Thank you, saved some time on this end too...

> Did you use https://www.qubes-os.org/doc/mutt/ to set it up? Apart from
> yum vs. dnf and what you mentioned, were there any other changes needed
> for R4.0?

Just updated to mention the package.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqETVoACgkQ24/THMrX
1yzRuAf9FE1e2n1G4HOqbwjJuOwtWbQDSMZ2VMxlKb9OFthAMo3ykZTjdNqTlioG
U22F4+LRQa/IsCDDc0EZrFyyJUX4nytWJNMWuKLK/1D71gg7kFol2zKCPLKsrFcx
xuLDLwetlxcfY9R99+VWATMjM1E07M/lbghMtchJp7DiG1hPmmXgLillYDVlYS3L
PPT2L3tw38O4WtC+iEU/m5gkVpKjdb4UxMXpY3KFhlFNZoYf312Gce+PxAXFTyIc
mDusWgQMgRJJSrwv3FjLMLsby8kW4lVQw0fafG5wewUv/EkZTb/zfAQL0rnn6d7y
dECHgFfNJD5/eYBJRER+CVgxSNYWOw==
=XpvY
-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/20180214145322.GB4877%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] can't install fail2ban or sshguard

2018-02-14 Thread Matus
Hello,

I'm using qubes os 3.2 with official template fedora 26 minimal. I tried 
installing fail2ban or sshguard but i get following error:

dnf install fail2ban
Failed to set locale, defaulting to C
Fedora 26 - x86_64 - Updates
  10 MB/s |  20 MB 00:01
Puppet Labs PC1 Repository fedora f26 - x86_64  
 4.0 MB/s | 104 kB 00:00
Qubes OS Repository for VM (updates)
 252 kB/s |  62 kB 00:00
Last metadata expiration check: 0:00:00 ago on Wed Feb 14 15:08:25 2018.
Error:
 Problem: conflicting requests
  - package fail2ban-0.9.7-2.fc26.noarch requires fail2ban-firewalld = 
0.9.7-2.fc26, but none of the providers can be installed
  - package fail2ban-0.9.6-4.fc26.noarch requires fail2ban-firewalld = 
0.9.6-4.fc26, but none of the providers can be installed
  - package fail2ban-firewalld-0.9.7-2.fc26.noarch requires firewalld, but none 
of the providers can be installed
  - package fail2ban-firewalld-0.9.6-4.fc26.noarch requires firewalld, but none 
of the providers can be installed
  - problem with installed package qubes-core-vm-3.2.22-1.fc26.x86_64
  - package qubes-core-vm-3.2.22-1.fc26.x86_64 conflicts with firewalld 
provided by firewalld-0.4.4.5-1.fc26.noarch
  - package qubes-core-vm-3.2.20-1.fc26.x86_64 conflicts with firewalld 
provided by firewalld-0.4.4.5-1.fc26.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or 
'--skip-broken' to skip uninstallable packages)

The qubes-core-vm have conflict with firewalld. Can I resolv this issue somehow 
or I can't use fail2ban or any other similar tool?

Thank you in advance for any help

-- 
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/98835d9f-6968-45b4-9ef0-edda17a22de0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Disk quota exceeded (when installing templates)

2018-02-14 Thread kveselnitskaya
On Saturday, February 4, 2017 at 11:51:08 AM UTC-5, john.david.r.smith wrote:
> hi.
> when using salt to install templates, i came across this error:
> 
> Sending application list and icons to dom0
> Complete!
> The downloaded packages were saved in cache until the next successful 
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> qfile-agent: Fatal error: File copy: Disk quota exceeded; Last file: 
> qubes-template-whonix-gw-3.0.6-201612182342.noarch.rpm (error type: Disk 
> quota exceeded)
> '/usr/lib/qubes/qrexec-client-vm dom0 qubes.ReceiveUpdates 
> /usr/lib/qubes/qfile-agent /var/lib/qubes/dom0-updates/packages/*.rpm' failed 
> with exit code 1!
> 
> how can i prevent this from happening? (i install templates one by one)
> currently i have a state shutting down my updatevm after each installation.
> Is there some better way?
> 
> -john



I found increasing the disk size of firewall VM used for updating allowed me to 
update Fedora 25. This can maybe work for your problem to update Whonix GW.

https://groups.google.com/forum/#!topic/qubes-users/kM1H6-ZLfM8

-- 
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/7a94755f-dcd3-48b2-8b14-a90e5820ad8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: HCL - HP ProBook 6565b

2018-02-14 Thread tsdelude
I think this model can be safely marked as not supporting IOMMU and thus a No 
for Qubes 4.0, if that is indeed a hard requirement for 4.x.

I'm not sure if there should be more Qubes 3.2 testing.

-- 
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/6dfabfac-84ff-413b-be3b-d0c3ed438137%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: HCL - HP ProBook 6565b

2018-02-14 Thread tsdelude
On Saturday, January 13, 2018 at 11:15:20 PM UTC-6, tsde...@gmail.com wrote:
> Type - Notebook
> HVM - Yes
> IOMMU - No
> SLAT - Yes
> TPM - Yes, present but untested
> Brand - HP
> Model - ProBook 6565b
> BIOS - Tried 68LTU Ver F.22 and F.64
> CPU - AMD A4-3310MX
> GPU -  AMD Radeon HD 6480G
> Network - Qualcomm Atheros AR9000 Series
> Memory - 8GB
> Qubes 3.2 - No
> Qubes 4.0-rc3 - No
> 
> Qubes 3.2 hangs on initial setup. Reboot causes loss of touchpad 
> functionality.
> Qubes 4.0-rc3 Start failed: internal error: libxenlight failed to create new 
> domain "sys-net"
> 
> Unable to complete qubes-hcl-report due to errors upon initial setup. Tried 
> BIOS updates. Tried manual BIOS config changes using HP BIOS Configuration 
> Utility.
> 
> -Thaddeus Delude

I noticed this hasn't appeared on the HCL list yet. Is there anything left to 
submit or test for this model to be put on the list? I'll be returning this 
model to work soon. I've already had it for a month for testing this project.

I wouldn't recommend using this model if you want it to work out of the box. 
I've tried quite a few other business class models. (five models to be exact) 
This is the only one I've had trouble with that wasn't already listed as having 
issues.

I tried everything I could think of with BIOS/EFI to get IOMMU to work, 
including HP's manual CLI BIOS config utility. It appears the CPU should 
support IOMMU but the motherboard does not. 

Qubes 3.2 hangs on initial setup for some reason. It wasn't any of the BIOS 
options. I most of them one at a time. (WiFi Switch, graphics options, 
Virtualization, Directed I/O, disabling devices, etc) I didn't investigate it 
much further than that. I'm guessing it was likely driver issues. It appears 
most people use Intel systems, so maybe it's an issues specific to some AMD 
processor families? The specific GPU in this model is integrated with the CPU. 
Qubes 4.0-rc3 also has errors along with a lack of IOMMU support.

-- 
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/73dc72ab-c0d6-41bd-8f55-3667cd577ef5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] R4 rc4 - Whonix System Time Error

2018-02-14 Thread 'sebuq' via qubes-users
The virgin whonix templates issue with official Qubes R4 rc4 downloads 
did not result in errors via whonixcheck. However after updating the 
whonix-gw template a get the following system time error:


ERROR: Systemd Clock Check Result:
Unexpected results by timedatectl.
timedatectl_output_pretty:
Local time: Wed 2018-02-14 10:25:33 UTC
Universal time: Wed 2018-02-14 10:25:33 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
It is generally recommended to keep the default as per Whonix Design. 
[1] If you did not change timezone related settings, please report this 
Whonix bug. If you know what you are doing and changed this on purpose, 
feel free to disable this check. [2]


[1] https://www.whonix.org/wiki/Dev/Design-Shared#timezone
[2] Create a file /etc/whonix.d/50_whonixcheck_user and add:
whonixcheck_skip_functions+=" check_systemd_clock "

--
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/bb1f3927-b495-e8d2-f1c4-f23cbe3f46c3%40dasamy.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Win7, qvm-copy-to-vm, QubesIncoming location?

2018-02-14 Thread Ivan Mitev



On 02/13/2018 10:34 PM, brendan.h...@gmail.com wrote:

On Tuesday, February 13, 2018 at 2:06:59 PM UTC-5, brenda...@gmail.com wrote:

On Friday, March 3, 2017 at 1:36:35 PM UTC-5, Martin L. Fällman wrote:

Does the issue still occur after You change the default Windows user in
Qubes settings? qvm-prefs -s windows default_user admin ?


Just tried it, yep. This is strange!


I am seeing the same issue with a Win7 HVM under R4.0rc4 using the qubes
windows drivers. First copy seems to work from a fedora VM but no file shows
up in windows. Additional attempts to copy says it failed because the file is
already there. Happens across reboots (fedora source says file is "there" but
nothing on the drives in windows).


Found it (windows 7 search explicitly skips the system directory, so it's a 
little difficult to discover).

The following directory is the receiving directory:

   C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\

Presumably this maps correctly for the account that qubes tools component is 
running under.

Just FYI, in case someone else runs into this.


I did run into this a few days ago...

I've just opened an issue to track those things:

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

BTW, did you manage to build QWT ?

--
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/ba9c7dc6-3022-57c3-be10-38053744b546%40maa.bz.
For more options, visit https://groups.google.com/d/optout.