Re: [qubes-users] Qubes updater icon never gets cleared

2020-12-07 Thread Viktor Ransmayr 
Viktor Ransmayr schrieb am Sonntag, 6. Dezember 2020 um 12:18:17 UTC+1:

>
> Viktor Ransmayr schrieb am Samstag, 5. Dezember 2020 um 22:59:57 UTC+1:
>
>>
>> a...@qubes-os.org schrieb am Samstag, 5. Dezember 2020 um 22:29:45 UTC+1:
>>
>>> On 12/5/20 1:36 AM, Viktor Ransmayr wrote: 
>>> > Hello Qubes community, 
>>> > 
>>> > I noticed since yesterday, that the icon, which indicates that updates 
>>> are 
>>> > available, never gets cleared on my system, although I obviously try 
>>> to 
>>> > launch the updater in a timely fashion - and - the operation succeeds 
>>> ... 
>>> > 
>>> > Here's the log from the latest attempt: 
>>> > 
>>> > ### 
>>> > 
>>> > Updating fedora-32 
>>> > 
>>> > fedora-32: 
>>> > -- 
>>> > ID: dnf list updates --refresh >/dev/null 
>>> > Function: cmd.run 
>>> > Result: True 
>>> > Comment: Command "dnf list updates --refresh >/dev/null" run 
>>> > Started: 09:00:59.753451 
>>> > Duration: 8745.114 ms 
>>> > Changes: 
>>> > -- 
>>> > pid: 
>>> > 1077 
>>> > retcode: 
>>> > 0 
>>> > stderr: 
>>> > stdout: 
>>> > -- 
>>> > ID: update 
>>> > Function: pkg.uptodate 
>>> > Result: True 
>>> > Comment: Upgrade ran successfully 
>>> > Started: 09:01:10.612928 
>>> > Duration: 24382.315 ms 
>>> > Changes: 
>>> > -- 
>>> > ID: notify-updates 
>>> > Function: cmd.run 
>>> > Name: /usr/lib/qubes/upgrades-status-notify 
>>> > Result: True 
>>> > Comment: Command "/usr/lib/qubes/upgrades-status-notify" run 
>>> > Started: 09:01:34.995429 
>>> > Duration: 3878.256 ms 
>>> > Changes: 
>>> > -- 
>>> > pid: 
>>> > 1148 
>>> > retcode: 
>>> > 0 
>>> > stderr: 
>>> > stdout: 
>>> > 
>>> > Summary for fedora-32 
>>> >  
>>> > Succeeded: 3 (changed=2) 
>>> > Failed: 0 
>>> >  
>>> > Total states run: 3 
>>> > Total run time: 37.006 s 
>>> > 
>>> > ### 
>>> > 
>>> > Does anyone have an explanation - or - a suggestion what else to try? 
>>> - TIA! 
>>> > 
>>> > Viktor 
>>> > 
>>>
>>> This is probably: 
>>>
>>> https://github.com/QubesOS/qubes-issues/issues/6234 
>>>
>>> In which case, it's a known bug, and the fix is in current-testing. 
>>>
>>
>> Thanks for the link to this issue. - I'll spend some time tomorrow 
>> reading it in detail & will report back here ... 
>>
>
> Yes, it looks like that this is / was most likely the reason for the 
> 'hickup' on my system as well.
>
> In the meantime the situation has changed however on my system again!
>
> As I did report already initially I update my system in a timely fashion - 
> and - continued to do so, even while waiting for an anwer / response 
> related to "sudo dnf update --best --allowerasing" ...
>
> Today two more updates related to 'fedora-32' and 'whonix-gw-15' were 
> performed ...
>
> Result: Update of template 'whonix-gw-15' succeeded immediately - and - 
> the partial update of 'fedora-32' succeeded after multiple 'hickups'. - 
> However the Qubes Updater icon is still active - but - when I perform 'sudo 
> dnf update' in Dom0 the system now only reports:
>
 

> [vr@dom0 ~]$ sudo dnf update ### <- Layer-8 error ;-) - Should have 
> checked against [user@fedora-32] !!!
>
 

> Qubes OS Repository for Dom0 80 MB/s |  82 kB 
> 00:00
> Dependencies resolved.
> Nothing to do.
> Complete!
> [vr@dom0 ~]$ 
>
> while running the update of the 'fedora-32' template using the updater 
> still reports:
>
> Updating fedora-32
>
> fedora-32:
>   --
> ID: dnf list updates --refresh >/dev/null
>   Function: cmd.run
> Result: True
>Comment: Command "dnf list updates --refresh >/dev/null" run
>Started: 10:17:20.752975
>   Duration: 8103.878 ms
>Changes:   
> --
> pid:
> 1076
>
> retcode:
> 0
> stderr:
> stdout:
>   --
> ID: update
>   Function: pkg.uptodate
> Result: True
>Comment: Upgrade ran successfully
>Started: 10:17:30.963450
>   Duration: 26434.827 ms
>
>Changes:   
>   --
> ID: notify-updates
>   Function: cmd.run
>   Name: /usr/lib/qubes/upgrades-status-notify
> Result: True
>Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
>Started: 10:17:57.398477
>   Duration: 3940.383 ms
>
>Changes:   
> --
> pid:
> 1148
> retcode:
> 0
> stderr:
> stdout:
>   
>   Summary for fedora-32
>   
>   Succeeded: 3 (changed=2)
>   Failed:0
>   
>   Total states run: 3
>   Total run time:  38.479 s
>
> FYI: If it is important & interesting, I've logged the details of each 
> operation & can report them here or in the issue ...
>

I wanted to inform you, that I was finally able to clear / deactivate the 
icon

Re: [qubes-users] Are known cpu bugs a risk as long as I work with Qubes OS?

2020-12-07 Thread Andrew David Wong 

On 12/7/20 3:21 AM, Rainer Neumann wrote:

Thank you, Sven, for your answer to the topic of qubes-hcl-report. I have one 
aditional question.

If I type in a console "cat /proc/cpuinfo", I get an output, where one line is called 
"bugs". It looks like my cpu has a lot of bugs: null_seg, cpu_meltdown, spectre_v1, 
spectre_v2, spec_store_bypass, l1tf, mds, swapgs, itlb_multihit, srbds.

The producer of my computer offeres a bios and microprocessor update for the purpose to 
fix these bugs. It is an exe-file for Windows: 
https://www.dell.com/support/home/de-ch/drivers/driversdetails?driverid=5m70h&oscode=wt32a&productcode=optiplex-7010

Okay, lets say, we can trust Intel and the computer manufacturer. But is it 
really necesarry to install the update as long as I work with Qubes OS?

Kindly regards,
Rainer



Have a look at this:

https://unix.stackexchange.com/questions/456425/what-does-the-bugs-section-of-proc-cpuinfo-actually-show

Specifically:

"Dump the flags which denote we have detected and/or have applied bug 
workarounds to the CPU we're executing on, in a similar manner to the 
feature flags."


In other words, according to the commit that added it, the "bugs" 
section doesn't tell you whether your CPU is vulnerable to the things in 
the list. Maybe a mitigation has already been applied. Maybe it has 
merely been detected and nothing has been done about it. We have no way 
to tell just from this section. You would have to do further 
investigation into each of these in order to try to determine whether 
your CPU is currently vulnerable.


Here's a discussion about doing that:

https://www.reddit.com/r/linux/comments/8k3x3b/til_proccpuinfo_shows_architecture_bugs_such_as/

It specifically mentions checking in:

/sys/devices/system/cpu/vulnerabilities/

However, Qubes is different from a standard Linux OS, and we often take 
our own special steps to address security problems, so there may be 
additional mitigations on top of whatever is mentioned here. In 
addition, the unique architecture of Qubes makes certain classes of 
security vulnerabilities inapplicable, so it will probably depend on the 
specific nature of that particular bug.


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

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/03d264ba-9f7f-1146-e265-61fd536a8aa1%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [EXT] Re: [qubes-users] Qubes OS: .onion and links

2020-12-07 Thread Andrew David Wong 

On 12/7/20 3:58 PM, Andrew David Wong wrote:

On 12/6/20 5:13 PM, unman wrote:

On Mon, Dec 07, 2020 at 02:07:03AM +0100, Ulrich Windl wrote:

On 12/1/20 7:35 PM, 'disrupt_the_flow' via qubes-users wrote:

On November 30, 2020 8:15:14 PM UTC, Ulrich Windl
 wrote:

 Hi!

 I noticed when I click the link "upgrading Fedora TemplateVMs" 
found on
 the onion version of the page (using the tor browser of 
whonix), you are

 directed to a non-onion page
 (https://www.qubes-os.org/doc/template/fedora/upgrade/),  
  and 
you'll have

 to switch to onion again.

 In contrast when I click news items on
 
http://qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/news/ 


 I remain on onion sites.

 Regards,
 Ulrich


Hello Ulrich. What page exactly? I can't find such a page on the 
QubesOS

website.


http://qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/news/2020/06/30/fedora-32-templates-available/ 





Yes, the links on that page are hard coded to the clearnet site rather
than local links.
That's a mistake - but it is not peculiar to this page. A quick check
suggests that (almost?) all the news pages contain such links.
Thanks for pointing this out.



Ah, that's because people asked a long time ago for the News post plain 
text content to be copied into the body of messages to the mailing lists 
(not just a hyperlink to the website). At the time, it seemed easier 
just to include full URLs in the original Markdown source so that the 
plain text could more easily be copy/pasted into messages to the mailing 
lists, since the difference between absolute and relative links on the 
was transparent to users after Jekyll rendering. Of course, we did not 
foresee that something else would come to rely on the links to be 
relative rather than absolute. Now that this is the case, we can simply 
use relative links everywhere (including in these News posts) and write 
out the complete URLs when preparing the plain text content for the 
mailing lists.




I'm also converting existing links from absolute to relative and 
updating the doc guidelines on this point:


https://github.com/QubesOS/qubes-posts/pull/73
https://github.com/QubesOS/qubes-doc/pull/1100

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

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4b991a57-6cf1-0fbe-f06c-2362b88108cf%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [EXT] Re: [qubes-users] Qubes OS: .onion and links

2020-12-07 Thread Andrew David Wong 

On 12/6/20 5:13 PM, unman wrote:

On Mon, Dec 07, 2020 at 02:07:03AM +0100, Ulrich Windl wrote:

On 12/1/20 7:35 PM, 'disrupt_the_flow' via qubes-users wrote:

On November 30, 2020 8:15:14 PM UTC, Ulrich Windl
 wrote:

 Hi!

 I noticed when I click the link "upgrading Fedora TemplateVMs" found on
 the onion version of the page (using the tor browser of whonix), you are
 directed to a non-onion page
 (https://www.qubes-os.org/doc/template/fedora/upgrade/),  
  and you'll have
 to switch to onion again.

 In contrast when I click news items on
 http://qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/news/
 I remain on onion sites.

 Regards,
 Ulrich


Hello Ulrich. What page exactly? I can't find such a page on the QubesOS
website.


http://qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/news/2020/06/30/fedora-32-templates-available/



Yes, the links on that page are hard coded to the clearnet site rather
than local links.
That's a mistake - but it is not peculiar to this page. A quick check
suggests that (almost?) all the news pages contain such links.
Thanks for pointing this out.



Ah, that's because people asked a long time ago for the News post plain 
text content to be copied into the body of messages to the mailing lists 
(not just a hyperlink to the website). At the time, it seemed easier 
just to include full URLs in the original Markdown source so that the 
plain text could more easily be copy/pasted into messages to the mailing 
lists, since the difference between absolute and relative links on the 
was transparent to users after Jekyll rendering. Of course, we did not 
foresee that something else would come to rely on the links to be 
relative rather than absolute. Now that this is the case, we can simply 
use relative links everywhere (including in these News posts) and write 
out the complete URLs when preparing the plain text content for the 
mailing lists.


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

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3ddea903-185f-123b-69cc-f4fb73135519%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Are known cpu bugs a risk as long as I work with Qubes OS?

2020-12-07 Thread 'awokd' via qubes-users 

Rainer Neumann:

Thank you, Sven, for your answer to the topic of qubes-hcl-report. I have one 
aditional question.

If I type in a console "cat /proc/cpuinfo", I get an output, where one line is called 
"bugs". It looks like my cpu has a lot of bugs: null_seg, cpu_meltdown, spectre_v1, 
spectre_v2, spec_store_bypass, l1tf, mds, swapgs, itlb_multihit, srbds.

The producer of my computer offeres a bios and microprocessor update for the purpose to 
fix these bugs. It is an exe-file for Windows: 
https://www.dell.com/support/home/de-ch/drivers/driversdetails?driverid=5m70h&oscode=wt32a&productcode=optiplex-7010

Okay, lets say, we can trust Intel and the computer manufacturer. But is it 
really necesarry to install the update as long as I work with Qubes OS?


Not necessary I suppose, since Xen runs a (temporary) microcode update 
when it boots, but would not be a bad idea to update the bios anyways in 
case some bug breaks the microcode patching on boot or you boot some 
other OS some day that does not include this step on boot.


--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2e3e9513-9964-bd82-50ad-0b1b87fbd465%40danwin1210.me.

Re: [qubes-users] Not detecting hdmi or usb-c external Monitor

2020-12-07 Thread 'awokd' via qubes-users 

Hayden Llowarch:

Hi guys,
My laptop with qubes was working fine with my external monitor however now it 
doesn’t even detect the monitor. It doesn’t even appear in xrandr.
All I get is:
Failed to get size of gamma for output default

I have made sure that I reset the gui-videoram-min to cover the screensize.

I have ruled out that its not the monitor or cable
  Any ideas how I can get it working again?


Try rebooting with an older kernel maybe? See 
https://www.qubes-os.org/doc/software-update-dom0/#changing-default-kernel.



--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/45be9def-22d4-bf0c-9717-459ba4a17875%40danwin1210.me.

Re: [qubes-users] Are "smart" monitors/TVs a security issue?

2020-12-07 Thread 'awokd' via qubes-users 

Andrew David Wong:

Since I never planned to use the voice features, I simply found a sewing 
needle, inserted it into the mic hole, and used a flat piece of hard 
plastic on the other end to apply moderate force. There was a single 
"click" sound. After that, voice commands were no longer recognized by 
the TV, but the remote and everything else still worked perfectly. 


Reminds me of a lobotomy procedure.

Thread related- if you want a big screen picture, but not "smarts", 
sometimes projectors can be the way to go.


--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6fcb60ce-0861-2e2d-085a-99777fc483cf%40danwin1210.me.

Re: [qubes-users] Recover from bootloop after failed kernel install

2020-12-07 Thread 'awokd' via qubes-users 

River~~:


Am I right in assuming that until Qubes 5 there is no solution within
the Qubes system? Meaning that I will need to boot with Knoppix or
some other live distro ??


There is/was a rescue option while booting from the Qubes installer. I 
think it is on the boot menu, so I'm not quite sure how to access if 
booting EFI.


--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/237045ce-1fb8-e65b-26ba-3d6ec08aeab2%40danwin1210.me.

Re: [qubes-users] How to recover files from a broken qubes pertition on ubuntu live CD?

2020-12-07 Thread 'awokd' via qubes-users 

Guerlan:

My Qubes worked great but after a day it suddenly wouldn't boot and I got
an error about qubes_dom0 root or something like that being not available. I

I mounted, on Ubuntu live CD, a LUKS partition that has these lvm
containers from Qubes OS:


 ubuntu@ubuntu:~$ sudo lvs
   LV VG Attr
LSizePool   Origin Data%
Meta%  Move Log Cpy%Sync Convert
   pool00 qubes_dom0 twi---tz--
<452.86g
  
   root   qubes_dom0 Vwi---tz--

<452.86g
pool00
  
   swap   qubes_dom0

-wi-a-
8.96g
  
   vm-anon-whonix-private qubes_dom0

Vwi---tz--2.00g
pool00
  
   vm-bitpay-private  qubes_dom0

Vwi---tz--2.00g pool00
vm-bitpay-private-1604634684-back
  
   vm-bitpay-private-1604634684-back  qubes_dom0

Vwi---tz--2.00g
pool00
  
   vm-debian-10-private   qubes_dom0

Vwi---tz--2.00g
pool00
  
   vm-debian-10-root  qubes_dom0

Vwi---tz--   10.00g pool00
vm-debian-10-root-1604634337-back
  
   vm-debian-10-root-1604634337-back  qubes_dom0

Vwi---tz--   10.00g
pool00
  
   vm-debian-sys-net-private  qubes_dom0

Vwi---tz--2.00g pool00
vm-debian-sys-net-private-1600569197-back
  
   vm-debian-sys-net-private-1600569197-back  qubes_dom0

Vwi---tz--2.00g
pool00
  
   vm-debian-temp-private qubes_dom0

Vwi---tz--2.00g
pool00
  
   vm-debian10-coding-private qubes_dom0

Vwi---tz--2.00g
pool00
  
   vm-debian10-coding-rootqubes_dom0

Vwi---tz--   10.00g pool00
vm-debian10-coding-root-1604634103-back
  
   vm-debian10-coding-root-1604634103-backqubes_dom0

Vwi---tz--   10.00g
pool00
  
   vm-default-mgmt-dvm-privatequbes_dom0

Vwi---tz--2.00g
pool00
  
   vm-fedora-29-dvm-private   qubes_dom0

Vwi---tz--2.00g
pool00
  
   vm-fedora-29-private   qubes_dom0

Vwi---tz--2.00g
pool00
  
   vm-fedora-29-root  qubes_dom0

Vwi---tz--   10.00g pool00
vm-fedora-29-root-1599172317-back
  
   vm-fedora-29-root-1599172317-back  qubes_dom0

Vwi---tz--   10.00g
pool00
  
   vm-hacking-private qubes_dom0

Vwi---tz--   20.00g pool00
vm-hacking-private-1602069716-back
  
   vm-hacking-private-1602069716-back qubes_dom0

Vwi---tz--   20.00g
pool00
  
   vm-multipurpose-privatequbes_dom0

Vwi---tz--   11.00g pool00
vm-multipurpose-private-1589207893-back
  
   vm-multipurpose-private-1589207893-backqubes_dom0

Vwi---tz--   11.00g
pool00
  
   vm-orwell3-private qubes_dom0 Vwi---tz--

137.00g pool00
vm-orwell3-private-1602465727-back
  
   vm-orwell3-private-1602465727-back qubes_dom0 Vwi---tz--

137.00g
pool00
  
   vm-orwell4-private qubes_dom0 Vwi---tz--

117.23g pool00
vm-orwell4-private-1605439750-back
  
   vm-orwell4-private-1605439750-back qubes_dom0 Vwi---tz--

117.23g
pool00
  
   vm-orwell4-private-snapqubes_dom0 Vwi---tz--

117.23g pool00
vm-orwell4-private
  
   vm-orwell4-root-snap   qubes_dom0

Vwi---tz--   10.00g pool00
vm-debian10-coding-root
  
   vm-orwell4-volatilequbes_dom0

Vwi---tz--   10.00g
pool00
  
   vm-pcb-design-private  qubes_dom0

Vwi---tz--2.00g pool00
vm-pcb-design-private-1598425853-back
  
   vm-pcb-design-private-1598425853-back  qubes_dom0

Vwi---tz--2.00g
pool00
  
   vm-sd-flasher-private  qubes_dom0

Vwi---tz--   10.00g pool00
vm-sd-flasher-private-1596569587-back
  
   vm-sd-flasher-private-1596569587-back  qubes_dom0

Vwi---tz--   10.00g
pool00
  
   vm-social2-private qubes_dom0

Vwi---tz--   21.00g pool00
vm-social2-private-1605439747-back
  
   vm-social2-private-1605439747-back qubes_dom0

Vwi---tz--   21.00g
pool00
  
   vm-social2-private-snapqubes_dom0

Vwi---tz--   21.00g pool00
vm-social2-private
  
   vm-social2-root-snap   qubes_dom0

Vwi---tz--   10.00g pool00
vm-debian-10-root
  
   vm-social2-volatilequbes_dom0

Vwi---tz--   10.00g
pool00
  
   vm-sys-firewall-privatequbes_dom0

Vwi---tz--2.00g pool00
vm-sys-firewall-private-1588756764-back
  
   vm-sys-firewall-private-1588756764-backqubes_dom0

Re: [qubes-users] How to attach private storage from one AppVM to another AppVM (LVM)?

2020-12-07 Thread 'heinrich...@googlemail.com' via qubes-users 
sshfs sounds great since this probably allows me to also select the folders 
I want to share with the SMALL AppVM instead of revealing all files.

Thanks for taking the time to look into this and I'm looking forward to the 
push :)

On Monday, December 7, 2020 at 4:30:11 PM UTC+1 unman wrote:

> On Mon, Dec 07, 2020 at 06:56:47AM -0800, 'heinrich...@googlemail.com' 
> via qubes-users wrote:
> > >From one AppVM I need to temporarily access a large amount of files 
> from 
> > another AppVM. Can this be done without copying the files around?
> > 
> > *Background: *
> > I have a large amount of files stored in AppVM "BIG". That's hundreds of 
> GB 
> > in a separate pool on a spinning HDD.
> > I also have a small AppVM "SMALL" running a program that needs to access 
> > files from "BIG". This AppVM resides on a small SSD.
> > 
> > In the past I copied files from BIG to SMALL. But this takes time and I 
> > need to sort the files beforehand because there is not enough space on 
> the 
> > SSD. I don't want to do that anymore. It would be okay to allow AppVM 
> > "SMALL" to access files from "BIG"'s private storage directly.
> > 
> > Googling around tells me to mount "private.img", but I'm using LVM so 
> > that's not an option. But how can this be done? Can it be done? (Or is 
> > there even a better "file sharing" approach for this amount of data 
> without 
> > having to revert to a NAS?) 
> > 
> > Any tips are appreciated.
> > 
> > (I'm on Qubes OS v4 latest)
> > 
>
> Take a look at https://qubes-os.org/doc/mount-lvm-image/
> That explains how to mount an lvm image.
>
> Alternatively you could look at https://github.com/unman/qubes-sync
> where I outline how to rsync data over qrexec.
> I've updated that to include sshfs over qrexec, but don't seem to have
> pushed it up yet. That'll have to wait until the morning.
> But the principle is simple - run sshd on the target
> instead of rsyncd: use a forwarder, and then mount the remote directory
> using sshfs on the client. That removes the need to copy files around,
> and keeps a single archive accessible from other qubes.
> That should give you idea of how to get started - if you need help let
> me know and I'll try to help in the morning.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/909961b5-b4fc-4a34-90c0-f4614a4bede4n%40googlegroups.com.

Re: [qubes-users] How to attach private storage from one AppVM to another AppVM (LVM)?

2020-12-07 Thread 'heinrich...@googlemail.com' via qubes-users 
sshfs sounds great since this probably allows me to also select the folders 
I want to share with the SMALL AppVM instead of revealing all files.

Thanks for taking the time to look into this and I'm looking forward to the 
push :)

On Monday, December 7, 2020 at 4:30:11 PM UTC+1 unman wrote:

> On Mon, Dec 07, 2020 at 06:56:47AM -0800, 'heinrich...@googlemail.com' 
> via qubes-users wrote:
> > >From one AppVM I need to temporarily access a large amount of files 
> from 
> > another AppVM. Can this be done without copying the files around?
> > 
> > *Background: *
> > I have a large amount of files stored in AppVM "BIG". That's hundreds of 
> GB 
> > in a separate pool on a spinning HDD.
> > I also have a small AppVM "SMALL" running a program that needs to access 
> > files from "BIG". This AppVM resides on a small SSD.
> > 
> > In the past I copied files from BIG to SMALL. But this takes time and I 
> > need to sort the files beforehand because there is not enough space on 
> the 
> > SSD. I don't want to do that anymore. It would be okay to allow AppVM 
> > "SMALL" to access files from "BIG"'s private storage directly.
> > 
> > Googling around tells me to mount "private.img", but I'm using LVM so 
> > that's not an option. But how can this be done? Can it be done? (Or is 
> > there even a better "file sharing" approach for this amount of data 
> without 
> > having to revert to a NAS?) 
> > 
> > Any tips are appreciated.
> > 
> > (I'm on Qubes OS v4 latest)
> > 
>
> Take a look at https://qubes-os.org/doc/mount-lvm-image/
> That explains how to mount an lvm image.
>
> Alternatively you could look at https://github.com/unman/qubes-sync
> where I outline how to rsync data over qrexec.
> I've updated that to include sshfs over qrexec, but don't seem to have
> pushed it up yet. That'll have to wait until the morning.
> But the principle is simple - run sshd on the target
> instead of rsyncd: use a forwarder, and then mount the remote directory
> using sshfs on the client. That removes the need to copy files around,
> and keeps a single archive accessible from other qubes.
> That should give you idea of how to get started - if you need help let
> me know and I'll try to help in the morning.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b6366b52-eba5-4e9e-b214-c41ef0b0bf9en%40googlegroups.com.

Re: [qubes-users] How to attach private storage from one AppVM to another AppVM (LVM)?

2020-12-07 Thread unman 
On Mon, Dec 07, 2020 at 06:56:47AM -0800, 'heinrich...@googlemail.com' via 
qubes-users wrote:
> >From one AppVM I need to temporarily access a large amount of files from 
> another AppVM. Can this be done without copying the files around?
> 
> *Background: *
> I have a large amount of files stored in AppVM "BIG". That's hundreds of GB 
> in a separate pool on a spinning HDD.
> I also have a small AppVM "SMALL" running a program that needs to access 
> files from "BIG". This AppVM resides on a small SSD.
> 
> In the past I copied files from BIG to SMALL. But this takes time and I 
> need to sort the files beforehand because there is not enough space on the 
> SSD. I don't want to do that anymore. It would be okay to allow AppVM 
> "SMALL" to access files from "BIG"'s private storage directly.
> 
> Googling around tells me to mount "private.img", but I'm using LVM so 
> that's not an option. But how can this be done? Can it be done? (Or is 
> there even a better "file sharing" approach for this amount of data without 
> having to revert to a NAS?) 
> 
> Any tips are appreciated.
> 
> (I'm on Qubes OS v4 latest)
> 

Take a look at https://qubes-os.org/doc/mount-lvm-image/
That explains how to mount an lvm image.

Alternatively you could look at https://github.com/unman/qubes-sync
where I outline how to rsync data over qrexec.
I've updated that to include sshfs over qrexec, but don't seem to have
pushed it up yet. That'll have to wait until the morning.
But the principle is simple - run sshd on the target
instead of rsyncd: use a forwarder, and then mount the remote directory
using sshfs on the client. That removes the need to copy files around,
and keeps a single archive accessible from other qubes.
That should give you idea of how to get started - if you  need help let
me know and I'll try to help in the morning.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201207153004.GA12349%40thirdeyesecurity.org.

Re: [qubes-users] Are known cpu bugs a risk as long as I work with Qubes OS?

2020-12-07 Thread Sven Semmler 

Hi Rainer, you wrote:

Okay, lets say, we can trust Intel and the computer manufacturer.
But is it really necesarry to install the update as long as I work
with Qubes OS?


I answer so you know I am not ignoring you. The fact is that I am not 
qualified to answer this question. I hope someone like unman will come 
and address it.


/Sven

--
 public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/63240f38-5d79-8e63-9767-c789abeb682b%40SvenSemmler.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] How to attach private storage from one AppVM to another AppVM (LVM)?

2020-12-07 Thread 'heinrich...@googlemail.com' via qubes-users 
>From one AppVM I need to temporarily access a large amount of files from 
another AppVM. Can this be done without copying the files around?

*Background: *
I have a large amount of files stored in AppVM "BIG". That's hundreds of GB 
in a separate pool on a spinning HDD.
I also have a small AppVM "SMALL" running a program that needs to access 
files from "BIG". This AppVM resides on a small SSD.

In the past I copied files from BIG to SMALL. But this takes time and I 
need to sort the files beforehand because there is not enough space on the 
SSD. I don't want to do that anymore. It would be okay to allow AppVM 
"SMALL" to access files from "BIG"'s private storage directly.

Googling around tells me to mount "private.img", but I'm using LVM so 
that's not an option. But how can this be done? Can it be done? (Or is 
there even a better "file sharing" approach for this amount of data without 
having to revert to a NAS?) 

Any tips are appreciated.

(I'm on Qubes OS v4 latest)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5d42e07f-9170-4504-bbc4-d638d2403cfcn%40googlegroups.com.

[qubes-users] Are known cpu bugs a risk as long as I work with Qubes OS?

2020-12-07 Thread Rainer Neumann 
Thank you, Sven, for your answer to the topic of qubes-hcl-report. I have one 
aditional question.

If I type in a console "cat /proc/cpuinfo", I get an output, where one line is 
called "bugs". It looks like my cpu has a lot of bugs: null_seg, cpu_meltdown, 
spectre_v1, spectre_v2, spec_store_bypass, l1tf, mds, swapgs, itlb_multihit, 
srbds.

The producer of my computer offeres a bios and microprocessor update for the 
purpose to fix these bugs. It is an exe-file for Windows: 
https://www.dell.com/support/home/de-ch/drivers/driversdetails?driverid=5m70h&oscode=wt32a&productcode=optiplex-7010

Okay, lets say, we can trust Intel and the computer manufacturer. But is it 
really necesarry to install the update as long as I work with Qubes OS?

Kindly regards,
Rainer

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8b7834a5-8d83-2183-9148-cb7eaa2b7cbe%40posteo.de.

Re: [qubes-users] Re: Someone should port this RDP Windows windower thing for Qubes

2020-12-07 Thread Alex Smirnoff 
Apparently, it is not going to work, too :(

https://github.com/FreeRDP/FreeRDP/issues/6640

Chances we get seamless windows apps anytime soon are slim.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a92daad1-889a-4e7b-a6d0-b98f3762d6f9n%40googlegroups.com.