date:20190103

Thanks 799...I learned something!

Similar to 799 but less hardcore...I always download a fresh template(vs 
upgrade). In my case I ran with a full/fresh Fedora-29 after the Fedora-28 
hplip issues, and added any new software from fresh:

https://www.qubes-os.org/doc/templates/

-- 
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/35179791-efe0-4634-90aa-af5f8b4d799f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] fail to install qubes-template-fedora-29 "Failed writing body"

Am Fr., 4. Jan. 2019, 01:46 hat pixel fairy 
geschrieben:

> $ sudo qubes-dom0-update qubes-template-fedora-29
> [...]
> Downloading Packages:
> [MIRROR] qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm: Curl
> error (23): Failed writing received data to disk/application for
> https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm
> [Failed writing body (8615 != 16384)]
> [FAILED] qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm: Curl
> error (23): Failed writing received data to disk/application for
> https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm
> [Failed writing body (8615 != 16384)]
> [...]


Do you have enough free space in sys-firewall (df -h)

- O

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ3yz2vzYZwFZJ8owD7CDq352ZED2%2BkC5uqTinKQLVy_c%3DSMrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] fail to install qubes-template-fedora-29 "Failed writing body"

2019-01-03 Thread pixel fairy

$ sudo qubes-dom0-update qubes-template-fedora-29
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some
time...
sys-firewall: command failed with code: 1
Fedora 25 - x86_64 - Updates2.5 MB/s | 24 MB 00:09
Fedora 25 - x86_64 2.1 MB/s | 50 MB 00:24
Qubes Dom0 Repository (updates) 1.1 MB/s | 7.7 MB 00:06
determining the fastest mirror (8 hosts).. done.
Qubes Templates repository 82 kB/s | 10 kB 00:00
Last metadata expiration check: 0:00:00 ago on Thu Jan 3 16:35:37 2019.
Dependencies resolved.

Package Arch Version Repository Size

Installing:
qubes-template-fedora-29 noarch 4.0.1-201812091508 qubes-templates-itl 1.3 G

Transaction Summary

Install 1 Package

Total download size: 1.3 G
Installed size: 1.3 G
DNF will only download packages for the transaction.
Downloading Packages:
[MIRROR] qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm: Curl error
(23): Failed writing received data to disk/application for
https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm
[Failed writing body (8615 != 16384)]
[FAILED] qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm: Curl error
(23): Failed writing received data to disk/application for
https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm
[Failed writing body (8615 != 16384)]

The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
Curl error (23): Failed writing received data to disk/application for
https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm
[Failed writing body (8615 != 16384)]
sys-firewall: command failed with code: 1

--
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/89e71077-b2ab-4a36-826a-40578d2f5f54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: sys-firewall command failed with code : 1

In case the above links dont work:

> 
> Dom0 error:
https://groups.google.com/forum/#!topic/qubes-users/NSVB-s1zHCI
> 
> Fedora 28 error:
https://groups.google.com/forum/#!topic/qubes-users/gKxaTiQ3iZg

-- 
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/8bf1d811-d1f6-4953-a943-a40ed748338e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] old version of xscreensaver


On 01/03/2019 06:03 PM, Frédéric Pierret wrote:

We built the upstream package of xscreensaver in current-testing for
both Qubes 3.2 and 4.0.

Welcome back to XFCE Chris :D !


LOL, seriously?

The XFCE deficits are too numerous, unfortunately.

--

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/d1b88d66-6141-e8a2-6961-81b3150c5e58%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Qubes Update" icon (Sun Looking icon on top right)

On Thu, 3 Jan 2019 at 22:57, <22...@tutamail.com> wrote:

> After a recent update to Dom0 an icon appeared on the top right.
> [...]
> Any thoughts or suggestions on how to use/configure this feature?
>

I have also recognized some problems as the Update Icon keeps telling me
that there are updates for some of my templates.
But when I launch the updates via "NEXT" I get the message under Details:
"SKIP (nothing to do)"
But the icon keeps telling me that Updates are available.

As this is something new, it seems to me that this was introduced via a
dom0 update.
Maybe opening "Qubes Global Settings" and clicking on "Disable checking for
updates for all Qubes" might be a temporary fix?

- O

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ3yz2t-nFPFqS%2BOUh1ZM0XY%2BmfRy-jm8XZcDsC0or1BQTPBkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] fed29 templates/upgrade

Hello John,

On Fri, 4 Jan 2019 at 00:37, John S.Recdep  wrote:

> Hello, since there are now templates available with dom0 for fedora-29
> does that mean one could also upgrade from 28->29   safely in a
> similar/same way  as say from 26->27 27->28  etc
>

My recommendation is to rebuild your custom templates from a XXX-minimal
template.
this will also make sure that you know all manual steps to rebuild your
system from scratch.
I have scripts which are creating all the templates I need from dom0.
very good, if you want to start with fresh templates from time to time.

PS: could you plz remind me what the qvm command was to determine which
> templates are available via  sudo dom0 update?
>

The command you are looking for is (in dom0):
sudo qubes-dom0-update --action=search qubes-template

You will find more information here in the (excellent) Qubes Docs:
https://www.qubes-os.org/doc/software-update-dom0/

If you're fearless you can also look into other repositories and search for
packages there:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
--action=search qubes-template
sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
--action=search qubes-template
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable
--action=search qubes-template

regards

- O

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ3yz2s-NNp_2Czjxz8yUWRNJbL3imeF8R7fptBt7HhzLtaCUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] fed29 templates/upgrade

2019-01-03 Thread John S.Recdep

Hello, since there are now templates available with dom0 for fedora-29
does that mean one could also upgrade from 28->29   safely in a
similar/same way  as say from 26->27 27->28  etc

please advise


PS: could you plz remind me what the qvm command was to determine which
templates are available via  sudo dom0 update?

-- 
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/afb3ab54-44fd-60c6-51a8-7d48aa23f419%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?

2019-01-03 Thread gone



On 1/3/19 11:51 PM, Chris Laprise wrote:

On 01/03/2019 05:07 PM, gone wrote:


On 1/3/19 10:45 PM, Chris Laprise wrote:

On 01/03/2019 03:40 PM, gone wrote:

On 1/3/19 12:50 AM, unman wrote:

On Wed, Jan 02, 2019 at 05:08:50PM +0100, gone wrote:


On 1/1/19 10:19 PM, Chris Laprise wrote:

On 01/01/2019 02:37 PM, gone wrote:
Hello, 1st of all, I want to thank all the developers and 
supporters

for that great stuff called Qubes OS. My first question here after
some hard time of setting up version 4.0, updating it step by step
and studying is the following:

I have a debian-9 template running and for some application to get
installed on it I need Python with Version >= 3.6 as a 
prerequisite.


Since the preinstalled versions in debian-9 are 2.7 and 3.5 I
attempted to install version 3.6.4 from source as described at
https://www.rosehosting.com/blog/how-to-install-python-3-6-4-on-debian-9/ 


in order not to run into problems with incompatibilities when
switching to another repo.

Installing the build tools with "sudo apt-get install -y ..." 
worked

fine but the next step, downloading the source file, with

"wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz;

brings "... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘www.python.org’ "

As I am neither an expert nor an experienced 
from-source-installer I
need some help and hope to get it here. Thanks very much in 
advance

and all the best for 2019.



Installing from Debian testing is much easier and it has Python 
3.7.
Just set the default release as in the following link, then add 
a line
for "testing" in your /etc/apt/sources.list (and then 'apt 
update'):


https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version 




Thanks Chris for the explanation. Yes, it may be easier to change 
to the
testing repo, but in general I would like to stay on the stable 
path with
that template. Switching to the testing repo and 'apt update' 
would probably
cause trouble with other software running smoothly so far. Or can 
I use that

only for python install and then fall back?

If you follow the instructions that Chris linked to you should be 
fine.

apt update just updates the list of available packages. It doesn't in
itself do anything more.

By setting the default release to stable, you ensure that you wont be
"accidentally" installing stuff from testing. That will only 
happen if

you explicitly specify the testing repo:
apt-get -t testing install foo

I'd strongly recommend aptitude, which does an excellent job of 
dealing

with  packages from different releases, and allows you to explicilt
choose the version you want. It also lets you review in detail 
what the

consequnces will be , so you are always able to roll back.

And, of course, with Qubes it's trivial to clone the template, try 
out
your proposed update from testing, and make sure that everything 
works

fine before you commit your precious qubes to use the new template.

OK, I've done setting the default version to "testing" in the newly 
created /etc/apt/apt.conf but for the additional line in the 
sources.list I'm not sure, what really is to do.


I've tried it with

"deb http://deb.debian.org/debian stretch testing contrib non-free"

but that seems to be wrong, as I get the following output in the 
terminal:


user@debian-9:~$ sudo apt update
Hit:1 http://deb.qubes-os.org/r4.0/vm stretch InRelease
Hit:2 http://security-cdn.debian.org stretch/updates InRelease
Ign:3 http://cdn-fastly.deb.debian.org/debian stretch InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stretch Release
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Target Packages (contrib/binary-amd64/Packages) is configured 
multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Packages (contrib/binary-all/Packages) is configured 
multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Translations (contrib/i18n/Translat.and several more 
lines with W: at the beginning.


Sorry but I'm absolutely not familiar with that, although it's 
pretty interesting.


@unman: As soon as it will have worked this way I promise to try 
aptitude next ;-) .




The relevant advice here is "set the default release as in the 
following link...". Not set default release to testing! In this case 
it should be set to stretch because that's the Debian release you're 
using.


You should add testing only as an additional line in sources.list:

deb http://deb.debian.org/debian testing main



Oh sorry, Chris, I reported wrong. The default in apt.conf is 
correctly set to stable.


Thank you for the correct line to put in sources.list.


FWIW, the debian page isn't terribly clear about it. Also, I believe 
that if you set the default to "stable" instead of the more specific 
"stretch", the system could try to upgrade everything when buster 
(v10) becomes

Re: [qubes-users] old version of xscreensaver

2019-01-03 Thread Frédéric Pierret

We built the upstream package of xscreensaver in current-testing for
both Qubes 3.2 and 4.0.

Welcome back to XFCE Chris :D !

On 1/3/19 11:56 PM, Chris Laprise wrote:
> On 01/03/2019 02:00 PM, Achim Patzner wrote:
>> Am Mittwoch, den 02.01.2019, 20:42 -0800 schrieb pixel fairy:
>>> xscreensaver complains about being an old version. doubt this
>>> matters, but might scare some users.
>>
>> There are worse problems with it (and some of them depend on X and the
>> hardware you're running on) which might also warrant finding something
>> different. I just have to find some time for constant rebooting of my
>> system to create a meaningful bug report.
>>
>> (To give you an idea: Imagine a machine (let's call it Lenovo P52) with
>> multiple GPUs where certain output channels are connected to one of the
>> GPUs only starting a screen server. If you connect your second monitor
>> to the right port the screen saver will not blank one of them if you
>> start X without an appropriately xorg.conf... And to make things worse
>> it also depends on the GPU you are using and the phase of the moon.)
>
> The bad screensaver is one of the reasons I switched back to KDE, and
> why I recommend it to other Qubes users. The default environment
> doesn't rise to the level of an every day functional desktop.
>

-- 
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/ca740da3-7f3f-698d-104e-f01a481b2928%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] old version of xscreensaver

On 01/03/2019 02:00 PM, Achim Patzner wrote:

Am Mittwoch, den 02.01.2019, 20:42 -0800 schrieb pixel fairy:

xscreensaver complains about being an old version. doubt this matters, but
might scare some users.

There are worse problems with it (and some of them depend on X and the
hardware you're running on) which might also warrant finding something
different. I just have to find some time for constant rebooting of my
system to create a meaningful bug report.

(To give you an idea: Imagine a machine (let's call it Lenovo P52) with
multiple GPUs where certain output channels are connected to one of the
GPUs only starting a screen server. If you connect your second monitor
to the right port the screen saver will not blank one of them if you
start X without an appropriately xorg.conf... And to make things worse
it also depends on the GPU you are using and the phase of the moon.)

The bad screensaver is one of the reasons I switched back to KDE, and
why I recommend it to other Qubes users. The default environment doesn't
rise to the level of an every day functional desktop.

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/280d3f50-9dfc-fddc-d4e5-e6d8013f1b60%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Help setting up a expressvpn proxy VM

On Thu, 3 Jan 2019 at 22:35, 799  wrote:

> [...]
> The obvious question which would maybe solve the autoconnection problem is:
>
> How can I make persistent changes to the following file/s which will
> survice the AppVM reboot:
> /rw/config/NM-system-connections/qubes-uplink-eth0
> /etc/NetworkManager/system-connections/qubes-uplink-eth0
> [...]
>

I found a way to update the file
/rw/config/NM-system-connections/qubes-uplink-eth0.

1) create a new file in /home/user/qubes-uplink-eth0.new
[connection]
id=VM uplink eth0
uuid=de85f79b-8c3d-405f-a652-cb4c10b4f9ef
type=ethernet
permissions=
secondaries=e3ced633-e808-408c-be1b-577522e7b28a;
timestamp=1546552856

[ethernet]
mac-address-blacklist=

[ipv4]
address1=10.137.0.17/32,10.137.0.5
dns=10.139.1.1;10.139.1.2;
dns-search=
may-fail=false
method=manual

[ipv6]
addr-gen-mode=eui64
dns-search=
ip6-privacy=0
method=ignore

2)  I then edited /rw/config/rc.local and added the following line:
cp /home/user/qubes-uplink-eth0.new
/rw/config/NM-system-connections/qubes-uplink-eth0
rc.local will run on start of the AppVM and therefore the Network Manager
config files will be updated.

Unfortunately the VPN is still not launching automatically, as the Setting
"" is disabled, even when the config files include the settings
secondaries=...
Launching Network Manager and Edit the connection "VM uplink eth0 will show
that the "Automatically connect to VPN when using this connection" is
disabled again.

If I enable the setting again no change will be done to the config files
and therefore the settings seems to be correct.
Additionally Autoconnecting the VPN is working after enablng the option
again.

Therefore I know that something is wrong, but I just don't know where to
look further :-/

- O

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ3yz2vzNxEDmoqL-jKbxTixQXh1aGGS2EAvCWFYK3K%2BAN-OWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?


On 01/03/2019 05:07 PM, gone wrote:


On 1/3/19 10:45 PM, Chris Laprise wrote:

On 01/03/2019 03:40 PM, gone wrote:

On 1/3/19 12:50 AM, unman wrote:

On Wed, Jan 02, 2019 at 05:08:50PM +0100, gone wrote:


On 1/1/19 10:19 PM, Chris Laprise wrote:

On 01/01/2019 02:37 PM, gone wrote:

Hello, 1st of all, I want to thank all the developers and supporters
for that great stuff called Qubes OS. My first question here after
some hard time of setting up version 4.0, updating it step by step
and studying is the following:

I have a debian-9 template running and for some application to get
installed on it I need Python with Version >= 3.6 as a prerequisite.

Since the preinstalled versions in debian-9 are 2.7 and 3.5 I
attempted to install version 3.6.4 from source as described at
https://www.rosehosting.com/blog/how-to-install-python-3-6-4-on-debian-9/ 


in order not to run into problems with incompatibilities when
switching to another repo.

Installing the build tools with "sudo apt-get install -y ..." worked
fine but the next step, downloading the source file, with

"wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz;

brings "... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘www.python.org’ "

As I am neither an expert nor an experienced from-source-installer I
need some help and hope to get it here. Thanks very much in advance
and all the best for 2019.



Installing from Debian testing is much easier and it has Python 3.7.
Just set the default release as in the following link, then add a 
line

for "testing" in your /etc/apt/sources.list (and then 'apt update'):

https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version 




Thanks Chris for the explanation. Yes, it may be easier to change 
to the
testing repo, but in general I would like to stay on the stable 
path with
that template. Switching to the testing repo and 'apt update' would 
probably
cause trouble with other software running smoothly so far. Or can I 
use that

only for python install and then fall back?


If you follow the instructions that Chris linked to you should be fine.
apt update just updates the list of available packages. It doesn't in
itself do anything more.

By setting the default release to stable, you ensure that you wont be
"accidentally" installing stuff from testing. That will only happen if
you explicitly specify the testing repo:
apt-get -t testing install foo

I'd strongly recommend aptitude, which does an excellent job of dealing
with  packages from different releases, and allows you to explicilt
choose the version you want. It also lets you review in detail what the
consequnces will be , so you are always able to roll back.

And, of course, with Qubes it's trivial to clone the template, try out
your proposed update from testing, and make sure that everything works
fine before you commit your precious qubes to use the new template.

OK, I've done setting the default version to "testing" in the newly 
created /etc/apt/apt.conf but for the additional line in the 
sources.list I'm not sure, what really is to do.


I've tried it with

"deb http://deb.debian.org/debian stretch testing contrib non-free"

but that seems to be wrong, as I get the following output in the 
terminal:


user@debian-9:~$ sudo apt update
Hit:1 http://deb.qubes-os.org/r4.0/vm stretch InRelease
Hit:2 http://security-cdn.debian.org stretch/updates InRelease
Ign:3 http://cdn-fastly.deb.debian.org/debian stretch InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stretch Release
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Target Packages (contrib/binary-amd64/Packages) is configured 
multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Packages (contrib/binary-all/Packages) is configured 
multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Translations (contrib/i18n/Translat.and several more 
lines with W: at the beginning.


Sorry but I'm absolutely not familiar with that, although it's pretty 
interesting.


@unman: As soon as it will have worked this way I promise to try 
aptitude next ;-) .




The relevant advice here is "set the default release as in the 
following link...". Not set default release to testing! In this case 
it should be set to stretch because that's the Debian release you're 
using.


You should add testing only as an additional line in sources.list:

deb http://deb.debian.org/debian testing main



Oh sorry, Chris, I reported wrong. The default in apt.conf is correctly 
set to stable.


Thank you for the correct line to put in sources.list.


FWIW, the debian page isn't terribly clear about it. Also, I believe 
that if you set the default to "stable" instead of the more specific 
"stretch", the system could try to upgrade everything when buster (v10) 
becomes the new stable (though I'm not sure if it would get anywhere

[qubes-users] Re: Questions

Just to dovetail Hugo, here was a similar discussion that included a few 
alternatives:

https://groups.google.com/forum/#!searchin/qubes-users/librem%7Csort:date/qubes-users/bu2jW28UJAY/Te-Z2y5GCAAJ

-- 
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/8096fd53-35b5-4872-bf8f-c8b9665fe2c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: sys-firewall command failed with code : 1

Not sure this explains your particular issues but:

Dom0 error:
https://groups.google.com/forum/#!searchin/qubes-users/22rip%7Csort:date/qubes-users/NSVB-s1zHCI/U-HCRz5uFAAJ

Fedora 28 error:
https://groups.google.com/forum/#!searchin/qubes-users/fedora$2028$20error$20update%7Csort:date/qubes-users/gKxaTiQ3iZg/t9b38WvuDgAJ

-- 
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/2219225c-c80d-4e2c-b504-3f4f675e4067%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?

2019-01-03 Thread gone




On 1/3/19 10:45 PM, Chris Laprise wrote:

On 01/03/2019 03:40 PM, gone wrote:

On 1/3/19 12:50 AM, unman wrote:

On Wed, Jan 02, 2019 at 05:08:50PM +0100, gone wrote:


On 1/1/19 10:19 PM, Chris Laprise wrote:

On 01/01/2019 02:37 PM, gone wrote:

Hello, 1st of all, I want to thank all the developers and supporters
for that great stuff called Qubes OS. My first question here after
some hard time of setting up version 4.0, updating it step by step
and studying is the following:

I have a debian-9 template running and for some application to get
installed on it I need Python with Version >= 3.6 as a prerequisite.

Since the preinstalled versions in debian-9 are 2.7 and 3.5 I
attempted to install version 3.6.4 from source as described at
https://www.rosehosting.com/blog/how-to-install-python-3-6-4-on-debian-9/ 


in order not to run into problems with incompatibilities when
switching to another repo.

Installing the build tools with "sudo apt-get install -y ..." worked
fine but the next step, downloading the source file, with

"wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz;

brings "... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘www.python.org’ "

As I am neither an expert nor an experienced from-source-installer I
need some help and hope to get it here. Thanks very much in advance
and all the best for 2019.



Installing from Debian testing is much easier and it has Python 3.7.
Just set the default release as in the following link, then add a 
line

for "testing" in your /etc/apt/sources.list (and then 'apt update'):

https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version 




Thanks Chris for the explanation. Yes, it may be easier to change 
to the
testing repo, but in general I would like to stay on the stable 
path with
that template. Switching to the testing repo and 'apt update' would 
probably
cause trouble with other software running smoothly so far. Or can I 
use that

only for python install and then fall back?


If you follow the instructions that Chris linked to you should be fine.
apt update just updates the list of available packages. It doesn't in
itself do anything more.

By setting the default release to stable, you ensure that you wont be
"accidentally" installing stuff from testing. That will only happen if
you explicitly specify the testing repo:
apt-get -t testing install foo

I'd strongly recommend aptitude, which does an excellent job of dealing
with  packages from different releases, and allows you to explicilt
choose the version you want. It also lets you review in detail what the
consequnces will be , so you are always able to roll back.

And, of course, with Qubes it's trivial to clone the template, try out
your proposed update from testing, and make sure that everything works
fine before you commit your precious qubes to use the new template.

OK, I've done setting the default version to "testing" in the newly 
created /etc/apt/apt.conf but for the additional line in the 
sources.list I'm not sure, what really is to do.


I've tried it with

"deb http://deb.debian.org/debian stretch testing contrib non-free"

but that seems to be wrong, as I get the following output in the 
terminal:


user@debian-9:~$ sudo apt update
Hit:1 http://deb.qubes-os.org/r4.0/vm stretch InRelease
Hit:2 http://security-cdn.debian.org stretch/updates InRelease
Ign:3 http://cdn-fastly.deb.debian.org/debian stretch InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stretch Release
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Target Packages (contrib/binary-amd64/Packages) is configured 
multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Packages (contrib/binary-all/Packages) is configured 
multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Translations (contrib/i18n/Translat.and several more 
lines with W: at the beginning.


Sorry but I'm absolutely not familiar with that, although it's pretty 
interesting.


@unman: As soon as it will have worked this way I promise to try 
aptitude next ;-) .




The relevant advice here is "set the default release as in the 
following link...". Not set default release to testing! In this case 
it should be set to stretch because that's the Debian release you're 
using.


You should add testing only as an additional line in sources.list:

deb http://deb.debian.org/debian testing main



Oh sorry, Chris, I reported wrong. The default in apt.conf is correctly 
set to stable.


Thank you for the correct line to put in sources.list.

--
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

[qubes-users] "Qubes Update" icon (Sun Looking icon on top right)

After a recent update to Dom0 an icon appeared on the top right. Been playing 
with it for a few weeks and I am struggling with the following:

1) It check for updates via sys-net even though I use sys-whonix for updates? I 
read some where there is a way to change this so it uses whonix which is more 
secure??
2) Most recent I used it to check my templates and it informed me "nothing to 
do", yet when I used the Qubes Manager to check/update I needed to update some 
templates? Not sure I can trust it to give accurate info...

Any thoughts or suggestions on how to use/configure this feature?

Thanks

-- 
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/e69c51ff-70ea-409c-97dc-22d890819703%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?


On 01/03/2019 03:40 PM, gone wrote:

On 1/3/19 12:50 AM, unman wrote:

On Wed, Jan 02, 2019 at 05:08:50PM +0100, gone wrote:


On 1/1/19 10:19 PM, Chris Laprise wrote:

On 01/01/2019 02:37 PM, gone wrote:

Hello, 1st of all, I want to thank all the developers and supporters
for that great stuff called Qubes OS. My first question here after
some hard time of setting up version 4.0, updating it step by step
and studying is the following:

I have a debian-9 template running and for some application to get
installed on it I need Python with Version >= 3.6 as a prerequisite.

Since the preinstalled versions in debian-9 are 2.7 and 3.5 I
attempted to install version 3.6.4 from source as described at
https://www.rosehosting.com/blog/how-to-install-python-3-6-4-on-debian-9/ 


in order not to run into problems with incompatibilities when
switching to another repo.

Installing the build tools with "sudo apt-get install -y ..." worked
fine but the next step, downloading the source file, with

"wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz;

brings "... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘www.python.org’ "

As I am neither an expert nor an experienced from-source-installer I
need some help and hope to get it here. Thanks very much in advance
and all the best for 2019.



Installing from Debian testing is much easier and it has Python 3.7.
Just set the default release as in the following link, then add a line
for "testing" in your /etc/apt/sources.list (and then 'apt update'):

https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version 





Thanks Chris for the explanation. Yes, it may be easier to change to the
testing repo, but in general I would like to stay on the stable path 
with
that template. Switching to the testing repo and 'apt update' would 
probably
cause trouble with other software running smoothly so far. Or can I 
use that

only for python install and then fall back?


If you follow the instructions that Chris linked to you should be fine.
apt update just updates the list of available packages. It doesn't in
itself do anything more.

By setting the default release to stable, you ensure that you wont be
"accidentally" installing stuff from testing. That will only happen if
you explicitly specify the testing repo:
apt-get -t testing install foo

I'd strongly recommend aptitude, which does an excellent job of dealing
with  packages from different releases, and allows you to explicilt
choose the version you want. It also lets you review in detail what the
consequnces will be , so you are always able to roll back.

And, of course, with Qubes it's trivial to clone the template, try out
your proposed update from testing, and make sure that everything works
fine before you commit your precious qubes to use the new template.

OK, I've done setting the default version to "testing" in the newly 
created /etc/apt/apt.conf but for the additional line in the 
sources.list I'm not sure, what really is to do.


I've tried it with

"deb http://deb.debian.org/debian stretch testing contrib non-free"

but that seems to be wrong, as I get the following output in the terminal:

user@debian-9:~$ sudo apt update
Hit:1 http://deb.qubes-os.org/r4.0/vm stretch InRelease
Hit:2 http://security-cdn.debian.org stretch/updates InRelease
Ign:3 http://cdn-fastly.deb.debian.org/debian stretch InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stretch Release
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Target Packages (contrib/binary-amd64/Packages) is configured 
multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Packages (contrib/binary-all/Packages) is configured multiple 
times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Translations (contrib/i18n/Translat.and several more lines 
with W: at the beginning.


Sorry but I'm absolutely not familiar with that, although it's pretty 
interesting.


@unman: As soon as it will have worked this way I promise to try 
aptitude next ;-) .




The relevant advice here is "set the default release as in the following 
link...". Not set default release to testing! In this case it should be 
set to stretch because that's the Debian release you're using.


You should add testing only as an additional line in sources.list:

deb http://deb.debian.org/debian testing main



--

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

Re: [qubes-users] Help setting up a expressvpn proxy VM

Hello Chris,

I have done some troubleshooting as I would like to see my VPN AppVM
automatically connect to my OpenVPN after it has been started up.

On Thu, 3 Jan 2019 at 19:55, Chris Laprise  wrote:

> I'm not sure. Probably you'd have to use Qubes 'binddirs'.
> You might want to test NM Autoconnect first, by disconnecting then
> re-connecting the virtual eth0 interface. You may encounter what we did
> (when step 4 was written): erratic behavior from NM that fails to
> reconnect the vpn.
>

I took a look at the following two files, which are identical
/rw/config/NM-system-connections/qubes-uplink-eth0
/etc/NetworkManager/system-connections/qubes-uplink-eth0

[802-3-ethernet]
duplex=full

[ethernet]
mac-address=00:16:3e:5e:6c:00

[connection]
id=VM uplink eth0
uuid=de85f79b-8c3d-405f-a652-cb4c10b4f9ef
type=802-3-ethernet

[ipv4]
method=manual
may-fail=false
dns=10.139.1.1;10.139.1.2
addresses1=10.137.0.17;32;10.137.0.5

[ipv6]
method=ignore

Launching Network Manager and Edit the connection "VM uplink eth0":
Tab: General
[X] Automatically connect to VPN when using this connection
OpenVPN-ExpressVPN

If I then reopen the configuration files above, the content has been
changed:

[ethernet]
mac-address=00:16:3E:5E:6C:00
mac-address-blacklist=

[connection]
id=VM uplink eth0
uuid=de85f79b-8c3d-405f-a652-cb4c10b4f9ef
type=ethernet

interface-name=eth0
***permissions=
***secondaries=e3ced633-e808-408c-be1b-577522e7b28a;
***timestamp=1546548963

[ipv4]
method=manual
may-fail=false
dns=10.139.1.1;10.139.1.2;
address1=10.137.0.17/32,10.137.0.5
***dns-search=

[ipv6]
method=ignore
***addr-gen-mode=eui64
***dns-search=
***ip6-privacy=0

Lines with marked with *** have been added after applying the change
(Autoconnect ...) in Network Manager.

I think the most important line is this one under [connection]:
secondaries=e3ced633-e808-408c-be1b-577522e7b28a;

As mentioned already this line references to UUID of the
OpenVPN-NetworkManager-config file which seems to be launched after the 1st
connection has been established.

As soon as I restart the VPN AppVM will reconnect the eth0 interface, but
NOT automatically initialize the OpenVPN connection.
I have to manually enable the VPN connection and the connection will be
established.
The changes to the config file stated above are lost and the config file
looks again like this:

cat /rw/config/NM-system-connections/qubes-uplink-eth0

[802-3-ethernet]
duplex=full

[ethernet]
mac-address=00:16:3e:5e:6c:00

[connection]
id=VM uplink eth0
uuid=de85f79b-8c3d-405f-a652-cb4c10b4f9ef
type=802-3-ethernet

[ipv4]
method=manual
may-fail=false
dns=10.139.1.1;10.139.1.2
addresses1=10.137.0.17;32;10.137.0.5

[ipv6]
method=ignore

The obvious question which would maybe solve the autoconnection problem is:

How can I make persistent changes to the following file/s which will
survice the AppVM reboot:
/rw/config/NM-system-connections/qubes-uplink-eth0
/etc/NetworkManager/system-connections/qubes-uplink-eth0

I tried to edit the file via ...
vi /rw/config/NM-system-connections/qubes-uplink-eth0
.. and got the following error message:

E325: ATTENTION
Found a swap file by the name
"/rw/config/NM-system-connections/.qubes-uplink-eth0.swp"
  owned by: root   dated: Thu Jan  3 01:48:00 2019
 file name: /rw/config/NM-system-connections/qubes-uplink-eth0
  modified: YES
 user name: root   host name: sys-vpn
process ID: 3232
While opening file "/rw/config/NM-system-connections/qubes-uplink-eth0"
 dated: Thu Jan  3 22:19:37 2019
  NEWER than swap file!

(1) Another program may be editing the same file.  If this is the case,
be careful not to end up with two different instances of the same
file when making changes.  Quit, or continue with caution.
(2) An edit session for this file crashed.
If this is the case, use ":recover" or "vim -r
/rw/config/NM-system-connections/qubes-uplink-eth0"
to recover the changes (see ":help recovery").
If you did this already, delete the swap file
"/rw/config/NM-system-connections/.qubes-uplink-eth0.swp"
to avoid this message.
"/rw/config/NM-system-connections/qubes-uplink-eth0" 18L, 286C

- O

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ3yz2tWq7uBvn8aN1w_D6Pj6v%2BurOth65ZEqa%3DrUqQinpKWzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?

2019-01-03 Thread gone

On 1/3/19 12:50 AM, unman wrote:

On Wed, Jan 02, 2019 at 05:08:50PM +0100, gone wrote:

On 1/1/19 10:19 PM, Chris Laprise wrote:

On 01/01/2019 02:37 PM, gone wrote:

Hello, 1st of all, I want to thank all the developers and supporters
for that great stuff called Qubes OS. My first question here after
some hard time of setting up version 4.0, updating it step by step
and studying is the following:

I have a debian-9 template running and for some application to get
installed on it I need Python with Version >= 3.6 as a prerequisite.

Since the preinstalled versions in debian-9 are 2.7 and 3.5 I
attempted to install version 3.6.4 from source as described at
https://www.rosehosting.com/blog/how-to-install-python-3-6-4-on-debian-9/
in order not to run into problems with incompatibilities when
switching to another repo.

Installing the build tools with "sudo apt-get install -y ..." worked
fine but the next step, downloading the source file, with

"wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz;

brings "... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘www.python.org’ "

As I am neither an expert nor an experienced from-source-installer I
need some help and hope to get it here. Thanks very much in advance
and all the best for 2019.

Installing from Debian testing is much easier and it has Python 3.7.
Just set the default release as in the following link, then add a line
for "testing" in your /etc/apt/sources.list (and then 'apt update'):

https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version

Thanks Chris for the explanation. Yes, it may be easier to change to the
testing repo, but in general I would like to stay on the stable path with
that template. Switching to the testing repo and 'apt update' would probably
cause trouble with other software running smoothly so far. Or can I use that
only for python install and then fall back?

If you follow the instructions that Chris linked to you should be fine.
apt update just updates the list of available packages. It doesn't in
itself do anything more.

By setting the default release to stable, you ensure that you wont be
"accidentally" installing stuff from testing. That will only happen if
you explicitly specify the testing repo:
apt-get -t testing install foo

I'd strongly recommend aptitude, which does an excellent job of dealing
with packages from different releases, and allows you to explicilt
choose the version you want. It also lets you review in detail what the
consequnces will be , so you are always able to roll back.

And, of course, with Qubes it's trivial to clone the template, try out
your proposed update from testing, and make sure that everything works
fine before you commit your precious qubes to use the new template.

OK, I've done setting the default version to "testing" in the newly
created /etc/apt/apt.conf but for the additional line in the
sources.list I'm not sure, what really is to do.

I've tried it with

"deb http://deb.debian.org/debian stretch testing contrib non-free"

but that seems to be wrong, as I get the following output in the terminal:

user@debian-9:~$ sudo apt update
Hit:1 http://deb.qubes-os.org/r4.0/vm stretch InRelease
Hit:2 http://security-cdn.debian.org stretch/updates InRelease
Ign:3 http://cdn-fastly.deb.debian.org/debian stretch InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stretch Release
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Target Packages (contrib/binary-amd64/Packages) is configured
multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Packages (contrib/binary-all/Packages) is configured multiple
times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10
W: Target Translations (contrib/i18n/Translat.and several more lines
with W: at the beginning.

Sorry but I'm absolutely not familiar with that, although it's pretty
interesting.

@unman: As soon as it will have worked this way I promise to try
aptitude next ;-) .

--
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/788341bd-aa8e-8165-78b1-e945f0d8948b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Help setting up a expressvpn proxy VM

2019-01-03 Thread Stuart Perkins




On Thu, 3 Jan 2019 19:24:31 +0100
799  wrote:

>Hello Stuart,
>
>On Thu, 3 Jan 2019 at 15:36, Stuart Perkins 
>wrote:
>
>> [...]
>> have an appVM which I use to connect via openconnect to a client's Cisco
>> VPN.  I installed the openconnect connection in that specific
>> appVM...program in the general template, but connection configuration only
>> in that appVM.
>> [...]
>>
>
>very interesting...
>... working within IT I also have the same need to connect to our office
>from outside and also to certain customers (who are also using Cisco gear)
>I have been able to install Cisco AnyConnect in a fedora-28-work template
>and have created AppVMs from it, which I use to connect via Cisco
>Anyconnect.
>Unfortunately I have been unable to create something like a Proxy VM.
>Do you mind sharing your setup how you're using OpenConnect to connect to
>Cisco VPNs?
>
>- O.

I execute open connect with a command of the form...

sudo /usr/sbin/openconnect "client's vpn server domain...'xx.yyy.com'" --config 
~/Client.conf

The only thing in the Client.conf file is authgroup and user, authgroup being 
the AD domain and user being my login network id.  

authgroup=DOMAIN-name
user=user-AD-id

I give my AD password when prompted and the shell stays active running the 
connection.  This allows me to connect where I used to have to use the Cisco 
VPN client under windows.  I close the connection with "ctrl-c" in the terminal 
window.  I've done this for years.

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

Re: [qubes-users] old version of xscreensaver

2019-01-03 Thread Achim Patzner

Am Mittwoch, den 02.01.2019, 20:42 -0800 schrieb pixel fairy:
> xscreensaver complains about being an old version. doubt this matters, but 
> might scare some users.

There are worse problems with it (and some of them depend on X and the
hardware you're running on) which might also warrant finding something
different. I just have to find some time for constant rebooting of my
system to create a meaningful bug report.

(To give you an idea: Imagine a machine (let's call it Lenovo P52) with
multiple GPUs where certain output channels are connected to one of the
GPUs only starting a screen server. If you connect your second monitor
to the right port the screen saver will not blank one of them if you
start X without an appropriately xorg.conf... And to make things worse
it also depends on the GPU you are using and the phase of the moon.)


Achim


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

Re: [qubes-users] Help setting up a expressvpn proxy VM

On 01/03/2019 01:43 PM, 799 wrote:

Hello Chris,

thanks for yor answer.

On Thu, 3 Jan 2019 at 03:55, Chris Laprise > wrote:

 > I thought I found out how to have OpenVPN auto-connect after the
sys-vpn
 > AppVM has launched:
 >
 > 1) right click in on the network manager applet icon of the
sys-vpn AppVM
 > 2) edit connections
 > 3) Choose the ethernet (NOT the VPN connection) and then preferences
 > 4) 1st Tab "General" choose "Automatically connect to VPN when using
 > this connection"
 > and choose the ExpressVPN connection here.
 >
 > As far as I understand this makes it unnecessary to run step 4
from the
 > Qubes VPN howto.

Actually IIRC step 4 was added because NM also has (or had) a bug in
its
automatic VPN startup.

As mentioned enabling the option "Automatically Connect to VPN..." is 
not persistent between rebooting the AppVM.
I have done some research and found out that if I enable this setting 
the following file will be changed:

/etc/NetworkManager/system-connections/qubes-uplink-eth0

Under the section [connection] you will find a new line which says:
secondaries=UUID;

This UUID is referencing to the UUID in the OpenVPN Connection file.
If I reboot the AppVM the change is not persistent.

The line is also present in 
/rw/config/NM-system-connections/qubes-uplink-eth0

What do I need to do, so that this change will survice a reboot?

I'm not sure. Probably you'd have to use Qubes 'binddirs'.

You might want to test NM Autoconnect first, by disconnecting then 
re-connecting the virtual eth0 interface. You may encounter what we did 
(when step 4 was written): erratic behavior from NM that fails to 
reconnect the vpn.

--

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/ad979e93-317f-d6d4-24f8-789c72b87d0c%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Which parts of qubes-builder are guaranteed to work/supported?

2019-01-03 Thread Achim Patzner

Am Donnerstag, den 03.01.2019, 00:02 + schrieb unman:
> On Wed, Jan 02, 2019 at 09:13:40PM +0100, Achim Patzner wrote:
> > Is it worth creating issues if certain parts of the Builder tools do
> > not work (e. g. template-local-centos7 or template-local-fc29+xfce)
> > which would be creating things not in the Qubes distribution?

> I would say ALL parts are "intended to work" rather than "guaranteed to work".

Let me rephrase it: Should bugs be reported to qubes-issues if the
affected item is not relevant for the generation of distribution-
related stuff? After all just reading it will bind resources that are
probably needed somewhere else.

> Anything that is included in builder *should* work - if it doesn't, it
> may be an issue, but I'd suggest raising it here first before heading
> over to github. You've already encountered this.

In that case a good example would be that make -j n (with n >=4) builds
of the targe qubes-vm are failing, right? (Which would also fix
rebuilding targets that have been finished already, too).

> (I exclude live iso build which hasnt worked as written for years.)

Maybe it should be removed...


Achim


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

Re: [qubes-users] Help setting up a expressvpn proxy VM

Hello Chris,

thanks for yor answer.

On Thu, 3 Jan 2019 at 03:55, Chris Laprise  wrote:

> > I thought I found out how to have OpenVPN auto-connect after the sys-vpn
> > AppVM has launched:
> >
> > 1) right click in on the network manager applet icon of the sys-vpn AppVM
> > 2) edit connections
> > 3) Choose the ethernet (NOT the VPN connection) and then preferences
> > 4) 1st Tab "General" choose "Automatically connect to VPN when using
> > this connection"
> > and choose the ExpressVPN connection here.
> >
> > As far as I understand this makes it unnecessary to run step 4 from the
> > Qubes VPN howto.
>
> Actually IIRC step 4 was added because NM also has (or had) a bug in its
> automatic VPN startup.
>

As mentioned enabling the option "Automatically Connect to VPN..." is not
persistent between rebooting the AppVM.
I have done some research and found out that if I enable this setting the
following file will be changed:
/etc/NetworkManager/system-connections/qubes-uplink-eth0

Under the section [connection] you will find a new line which says:
secondaries=UUID;

This UUID is referencing to the UUID in the OpenVPN Connection file.
If I reboot the AppVM the change is not persistent.

The line is also present in
/rw/config/NM-system-connections/qubes-uplink-eth0

What do I need to do, so that this change will survice a reboot?


> > Only step 5 ("Make the network fail-close for the AppVMs f the
> > connection to the VPN breaks") is then needed.
> Recommended.
>

and implemented :-)

[...]
> Under various circumstances, your vpn vm could behave like sys-firewall
> when the vpn connection stops. In such cases, traffic could pass through
> without encryption. The best blanket policy to stop any chance of that
> happening is in step 5.
>

ok, thanks for the clarification.

- O

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ3yz2tHJqSemqYMMu%2Brc-wPNoXe9mYQW%3D%3DU6kPj_8T_k96pYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Help setting up a expressvpn proxy VM