[qubes-users] Error updating imported TemplateVM(from 3.2) on 4.0

[grv]

Hi,

When I manually launch update on imported template vm(clone of debian-8 
template) I see errors like these:

Err http://deb.qubes-os.org stretch Release.gpg
  Cannot initiate the connection to 10.137.255.254:8082 (10.137.255.254). - 
connect (101: Network is unreachable)


One thing I noticed that imported template vm has this additional message on 
"firewall rules" tab:
"Firewall has been modified manually -- please use qvm-firewall for any further 
changes". This is message is not present on existing debian-9 template vm on 
4.0.

I have done many customization on the template vm and do not want to manually 
port all those to debian-9 template. Any suggestion to get update working on 
imported 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/a4538175-a13c-4538-ae5b-e3b967334b59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Restoring 3.2 Standalone VM on Qubes 4.0

[donoban]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/24/18 21:58, 'awokd' via qubes-users wrote:
> On Tue, April 24, 2018 7:02 pm, donoban wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> 
>> Hi,
>> 
>> 
>> I restored an standalone AppVM based on Fefodora 26. After trying
>> to run I saw Qubes GUI didn't work but I could get a bash console
>> from dom0 .
>> 
>> 
>> I removed qubes 3.2 repo, added 4 and run 'dnf update'. It
>> installed a lot of packages but now I can't run commands on it
>> from dom0 and GUI stills not working.
>> 
>> Any idea?
> 
> I did the same thing you did and wound up re-restoring the 3.2 VM, 
> creating a new AppVM in 4.0 to replace it, and then running
> qvm-copy-to-vm to copy data from the old to the new.

I will end probably doing it too :)


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlrfm14ACgkQFBMQ2OPt
CKUl5A/9HBRdBAnTcZqA1IMLunkyQOEuvGkxcXpFrFDc2oURYwnRf+0E5amxLmhA
cARNFKtw0ca4lLCEZBB/fU4bsPvAM3gxsKQTvtW55PV+MuarcMO2O1jP4XCBPa/N
36udqSeAh4JsPy/vuXkHwva+V8GpdQIFSox5KtdB0BqtXsYe3IKCqGQ7ydyXjI2j
UFHNRL/2tla+z5gvflRZwhFqY2rGHwZ975ournd5EpbkLSBjjqWm22tXBbMVIsG6
Qdl3joXFGP6KWeUglMNlQaQvvpFZqwyksiPGzbae5yrZdZs1QwYHqULXucLNRzUW
c9v1W3msPvLArmp+c44R/bU3UVi/Vey2cu75t3IssekC6n9Ol5DwSA2qVIkbMDUV
IMam0RWR66B6w2r5fw2z/G6Bz4+zKpDnP7fQeThiZ42Va0iiOod18jmeGyIfLE/i
/73e8qI/QXveS8znHf71PAhwOG1ALRnkeA0PnBhHjfz0WMbYwAcpqc1FoV8aWFUh
9w1rmTd/W6wIRCOpTgrmzV/SKMIk4lcVpxStPzoweoC+Sf9qMQc3PeMpvLNpYlj/
aZnw+DxjtqidtEuGdzn/pcQ75w3lBOhSdMQURLE+xnaxgyI+OcCeDgUMeuq8R1Lu
HQX5H/njjK8UXSgfpxm7DuwwB08sAWjorSQB7sD9X0Jf4m0biF0=
=7+yx
-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/7e102840-71e7-6ea6-b58b-c06ef85b83c7%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Restoring 3.2 Standalone VM on Qubes 4.0

['awokd' via qubes-users]

On Tue, April 24, 2018 7:02 pm, donoban wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Hi,
>
>
> I restored an standalone AppVM based on Fefodora 26. After trying to
> run I saw Qubes GUI didn't work but I could get a bash console from dom0 .
>
>
> I removed qubes 3.2 repo, added 4 and run 'dnf update'. It installed a
> lot of packages but now I can't run commands on it from dom0 and GUI stills
> not working.
>
> Any idea?

I did the same thing you did and wound up re-restoring the 3.2 VM,
creating a new AppVM in 4.0 to replace it, and then running qvm-copy-to-vm
to copy data from the old to the new.


-- 
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/49587bf5fc888cfa7816ff36593b3c99.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

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

[john]

oh sorry disregard , didn't realize you were referring to the  github 
tasket  vpn script  ??


funny, I believe he actually designs it for debian > fedora  :)

still, I guess we're to assume you downloaded the  PIA config files to 
the correct  dir  etc ?


https://helpdesk.privateinternetaccess.com/hc/en-us/articles/219438247-Installing-OpenVPN-PIA-on-Linux

--
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/8e6429c8-d210-b792-f1b5-5229ef5f3b13%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Restoring 3.2 Standalone VM on Qubes 4.0

[donoban]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I restored an standalone AppVM based on Fefodora 26. After trying to
run I saw Qubes GUI didn't work but I could get a bash console from dom0
.

I removed qubes 3.2 repo, added 4 and run 'dnf update'. It installed a
lot of packages but now I can't run commands on it from dom0 and GUI
stills not working.

Any idea?
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlrffzEACgkQFBMQ2OPt
CKV7xw//ZzPd6NLJZZz7l2D2TnAkOcJ0sQpIUtIQM8oufkW1lerDWAEpHCn3XV8J
+Mo1g+DxfnDf25XbbOb7SQ5Cowo/+o0aZPi9QeVBngUxR2biNun9fXb31ou7LDCg
khBOAU8QF64Nm/KArsOj0OmO68aTZ+i7pfAMfiHmNyE75mxDbXbyoZbfwTIADhrJ
WESqcSJqNj3Pk9w5Y8W1MzyGaZHT1VBgjmJbh9+TluKCKme5ZJNe9rHEybL/0PBx
2XUGUxcJviqtw7bYZEbBusWi4YKjXo8S8sU/pj+CsRf9p/zhFVGLLHtrDVTIfJtW
1AnYhoYpWiEAskDbT52SCu6Ir3H5XrOak4Z0PWT/rdd/ybhvWt+bH3i+7T0Q9MiG
m5Hn4y7QEJc2ei1o4wuzNR6uYMD+uUiididmUwvaVtzM6qhf8OkmHk6+a3cnmB3F
p/EcOKWJw0QFp/K7T33xI/MR62VyuZWaKpcxSHXNiw/AWCA34by7xRDz5kJdsMsi
/BNVPzCiCi8zFbognQVjrEtv33qCIZ05FMJW2MJfmJ39TbzMZHhvcDbLctBBopwf
Rs475SKMxFPtVuuf1UmzXOwy6q5fg2+TRXW9YGti/P2E+X3qU6/uIdbt+/YHeE4K
qJjc59dQhmIvhxdW3+u8QRj2dZaDMwGd5ytx0axkJalpMxfcIPE=
=ZSrP
-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/b5cd295d-77ab-dc68-6691-39edea98e9f1%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] IMG sharing

[799]

Hello Drew,

Drew White  schrieb am Di., 24. Apr. 2018, 07:14:

> Is it possible for every guest to share one virtual drive for cacheing and
> auto mounting to same location for file transfers?
>
> i.e. One file always mounted to each guest and one reads while one writes.
> etc. no need to mount and unmount? And it can be multiple images on
> different locations at once?
>

I haven't understand yet what you are trying to accomplish.
You want a file location ("drive") that is shared between VMs, and you want
that most VMs have read permissions to this location and one can write to
it?

As mentioned by others this kind of breaks the security model of Qubes but
I had a similar use case to work with data stored in a cloud service.

I wanted to separate data editing, local data storage and synchronization
to the cloud service.
The idea was that data is always encrypted in the "storage AppVM". Other
"AppVMs" can access this Storage AppVM using SSHfs.
I am using certificates and tight firewall configuration:
- the AppVM can request connection to the storage VM via ssh, login is done
via certificates.
- after authentication the remote location is mounted via SSHfs
- the data is encrypted with encfs and the decryption keys are only stored
on the AppVM which is accessing the data (not the storage VM)

This setup works quiet well for my usecase as it is less complex than
setting up a Fileserver with NFS to share data between AppVMs.

I know that this may not the best thing for a die hard Qubes user, but it
allows me to setup inter-AppVM data flows if needed for specific use cases.

I have also scripted everything so that the firewall ports will only be
opened when needed.

If you are interested I can upload my scripts/how-to to my GitHub account.

[799]

-- 
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/CAJ3yz2vvTj%3DmF2dcx537LF6u3TKCxAu0-ma_dMbOzsL9D4DMzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] To use Windows 7 OEM as a Qubes VM; which hardware metadata is needed?

[Stuart Perkins]

On Tue, 24 Apr 2018 18:28:19 +0200
Teqleez Motley  wrote:

>(Btw, I do of course have the license key, and I am NOT going to use that VM 
>online, so I do hopefully not need security updates or the like.)
>
>
>Regards,
>Teqleez
>

In that case, I would consider pulling the hard drive and using usb adapter to 
access the information without concern for battery life.  This is independent 
of whether or not you can cause the VM to think it is the original 
hardware..which I actually doubt at this point.

Stuart

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

Re: [qubes-users] To use Windows 7 OEM as a Qubes VM; which hardware metadata is needed?

[Teqleez Motley]

(Btw, I do of course have the license key, and I am NOT going to use that VM 
online, so I do hopefully not need security updates or the like.)


Regards,
Teqleez

-- 
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/1524587299.3824504.1349212016.4E848383%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] To use Windows 7 OEM as a Qubes VM; which hardware metadata is needed?

[Teqleez Motley]

Hi all,

One of my old laptops have Windows 7, and I would like to use that license for 
a Qubes (H)VM.

I have one question and one related concern:

a) which metadata is needed for that OEM to continue believing that it is the 
master OS and running on the "same" hardware as initially set up with?

b) That particular laptop has almost no battery left, and no available power 
supply..:
In case that laptop just have a minute or two left of battery, and I do not 
want to "test" if that is true..., I am looking for a way to fetch the needed 
metadata mentioned in a) with a script, to store it to a USB immediately ASAP 
after booting.

Obviously I dont need the Qubes OS itself to actually DO this, but would like 
to know if I can hope to achieve this at all.
Any tips/pointers would be much appreciated.

Regards,
Teqleez

-- 
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/1524587072.3823457.1349193440.1F418C62%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Created dvm appears as a normal AppVM instead of dvm

[cooloutac]

On Tuesday, April 24, 2018 at 5:54:11 AM UTC-4, qube...@tutanota.com wrote:
> I created the new dvm:
> 
> [user@dom0 ~]$ qvm-create --template debian-9 --label red deb-dvm-net
> [user@dom0 ~]$ qvm-prefs deb-dvm-net template_for_dispvms True
> [user@dom0 ~]$ qvm-features deb-dvm-net appmenus-dispvm 1
> 
> The created deb-dvm-net is seen in the Qube Manager as a normal AppVM.  
> 
> In the menu of Advanced - Default DispVM it can still be seen as a dvm.
> 
> Any ideas?

not sure, maybe you have to name it deb-net-dvm?

-- 
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/ca14fde4-4b89-42af-94b6-31195a6f5c72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Created dvm appears as a normal AppVM instead of dvm

[qubes-fan]

Sry, solved. 

Had to create an AppVM deb-dvm-net in advance through the Qube Manager. Than:

[user@dom0 ~]$ qvm-prefs deb-dvm-net template_for_dispvms True
[user@dom0 ~]$ qvm-features deb-dvm-net appmenus-dispvm 1

Now I can see the deb-dvm-net as a dvm in the Start menu as well. 


--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com 

24. Apr 2018 09:54 by qubes-...@tutanota.com :


> I created the new dvm:
>
> [user@dom0 ~]$ qvm-create --template debian-9 --label red deb-dvm-net
> [user@dom0 ~]$ qvm-prefs deb-dvm-net template_for_dispvms True
> [user@dom0 ~]$ qvm-features deb-dvm-net appmenus-dispvm 1
>
> The created deb-dvm-net is seen in the Qube Manager as a normal AppVM.  
>
> In the menu of Advanced - Default DispVM it can still be seen as a dvm.
>
> Any ideas?
>   
>
> -- 
> 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/LAr3lVk--3-0%40tutanota.com 
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

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

[qubes-users] Created dvm appears as a normal AppVM instead of dvm

[qubes-fan]

I created the new dvm:

[user@dom0 ~]$ qvm-create --template debian-9 --label red deb-dvm-net
[user@dom0 ~]$ qvm-prefs deb-dvm-net template_for_dispvms True
[user@dom0 ~]$ qvm-features deb-dvm-net appmenus-dispvm 1

The created deb-dvm-net is seen in the Qube Manager as a normal AppVM.  

In the menu of Advanced - Default DispVM it can still be seen as a dvm.

Any ideas?

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

Re: [qubes-users] IMG sharing

[Ivan Mitev]

On 04/24/2018 09:01 AM, Drew White wrote:
> On Tuesday, 24 April 2018 15:28:40 UTC+10, Ivan Mitev  wrote:
>> On 04/24/2018 08:14 AM, Drew White wrote:
>>> Is it possible for every guest to share one virtual drive for cacheing and 
>>> auto mounting to same location for file transfers?
>>
>> It isn't possible unless you set up a clustered file system, which
>> implies having in-band or out-of-band communication channels between
>> guests. This breaks compartmentalization, which is Qubes' raison d'etre,
>> so if you really need this you're better off ditching Qubes and go with
>> plain kvm (or xen) VMs.
>>
> 
> I'm not talking about for all guests. and the channel would be one image 
> file, read only.  Writable only by one guest that does the downloading 
> securely and checks and writes the files.

AFAIK it's not possible. You need a clustered FS to see changes in real
time; If you share an image/device you'll have to
- make sure the guest with write rights has fsync'ed the changes to the
FS and/or that no cache is involved.
- unmount/remount the shared volume in R/O guests each time you need to
read new files.

I have no idea if Qubes allows sharing a volume between guests; I'd
imagine that qvm-* commands won't allow that so that users don't shoot
themselves in the foot, but you may be able to achieve this with lower
level commands or by tweaking the qvm-* commands' source.

But since you're sending content from a VM to other guests, the security
level of your R/O guests is basically dependent on the one you download
files to, so you could open some firewall ports and setup a networked
clustered FS like glusterfs.


> 
> One guest has cache and write permissions, nothing else does. Thus, secure. 
> More secure than downloading the same thing 50 times.
> 

-- 
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/2b77ccc9-bed7-3095-7b47-b4616cb3f0e1%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] IMG sharing

[Drew White]

On Tuesday, 24 April 2018 15:28:40 UTC+10, Ivan Mitev  wrote:
> On 04/24/2018 08:14 AM, Drew White wrote:
> > Is it possible for every guest to share one virtual drive for cacheing and 
> > auto mounting to same location for file transfers?
> 
> It isn't possible unless you set up a clustered file system, which
> implies having in-band or out-of-band communication channels between
> guests. This breaks compartmentalization, which is Qubes' raison d'etre,
> so if you really need this you're better off ditching Qubes and go with
> plain kvm (or xen) VMs.
> 

I'm not talking about for all guests. and the channel would be one image file, 
read only.  Writable only by one guest that does the downloading securely and 
checks and writes the files.

One guest has cache and write permissions, nothing else does. Thus, secure. 
More secure than downloading the same thing 50 times.

-- 
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/48f543f9-1120-4443-ac73-092ac09156fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.