Re: [qubes-users] How to automate cloud backups of trusted vault files?
On 5/27/19 3:05 PM, David Hobach wrote: On 5/27/19 12:52 PM, 'Side Realiq' via qubes-users wrote: How to automate backups of files from a very trusted vault to the cloud? What are some best practices for that? My current issue is that the files in the trusted vault do not have internet connection, so the cloud backup software should not be running in the vault, and needs to run in a separate "backup" internet connected qube. But I don't know how I can automate copying the files from the vault to the backup qube. The qvm-copy command requires manual choice of the target VM, which is not automated. This depends on your Qubes RPC policy, which you can manage with the /etc/qubes-rpc/policy files in dom0. Also see [1]. So you can automate qvm-copy usage, if you want to. Another option is to entirely attach your data from the source VM to the backup VM using qvm-block, which should be faster as it doesn't involve copy operations between VMs. See e.g [2] for that method. I'd also recommend to a) use software you trust for backups. b) use encrypted containers (e.g. dm-crypt) for backups unless you completely trust your cloud provider (I certainly don't). [1] https://www.qubes-os.org/doc/rpc-policy/ [2] https://github.com/3hhh/blib/blob/master/lib/os/qubes4/dom0#L955 I had received another few private questions about this that I'd like to respond to: 1. "You mentioned "use encrypted containers" when backups are made they are encrypted correct? How about AppVMs, are they encrypted by default?" The default backups made by Qubes OS are encrypted and should be the overall preferred way of doing backups. Since the OP was asking about only backing up dedicated files rather than the entire AppVM (what the Qubes OS backup does), he'd have to implement the encryption part himself. It might make also sense to put the data meant to be backed up inside a dedicated VM and then use the default backup mechanism with your cloud provider. Of course you'd have to mount the cloud provider file system inside your backup VM first. Personally, I don't use the default mechanism for speed reasons - my internet connection is too slow to push 100+ GB over it for every backup. sparsebak might help here [3], but is not official yet. [3] https://github.com/tasket/sparsebak 2. "For option 2) the function b_dom0_attachVMDisk attaches "the entire private disk image (private.img) of the source VM to the target VM". In my vault there is a folder with the encrypted files, and another with decrypted files and I don't want to expose the decrpyted files to another VM. Can I attach only a specified folder (with the encrypted files) to another VM? If yes how?" You can only attach devices to other VMs with qvm-block. So you'd have to put your file inside a loop device, which you could then attach to the backup VM. If "encrypted files" means a dm-crypt container, you can map the decrypted data from your AppVM to your backup VM (cryptsetup creates a /dev/mapper/something device after decryption, which you can then use with qvm-block). I'll also release some software in a month or so to simplify dm-crypt usage with Qubes OS. Alternatively you could separate the files you'd like to backup from those you don't by using different VMs for them. -- 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/e3344f77-9258-2a41-fd5a-1720ae7d5f13%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] How to automate cloud backups of trusted vault files?
> > From: Chris Laprise > Sent: Mon May 27 19:58:35 CEST 2019 > To: David Hobach , Side Realiq > , > Subject: Re: [qubes-users] How to automate cloud backups of trusted vault > files? > > > On 5/27/19 9:05 AM, David Hobach wrote: > > > > > > On 5/27/19 12:52 PM, 'Side Realiq' via qubes-users wrote: > >> How to automate backups of files from a very trusted vault to the > >> cloud? What are some best practices for that? > >> > >> My current issue is that the files in the trusted vault do not have > >> internet connection, so the cloud backup software should not be > >> running in the vault, and needs to run in a separate "backup" internet > >> connected qube. But I don't know how I can automate copying the files > >> from the vault to the backup qube. The qvm-copy command requires > >> manual choice of the target VM, which is not automated. > > > > This depends on your Qubes RPC policy, which you can manage with the > > /etc/qubes-rpc/policy files in dom0. Also see [1]. > > So you can automate qvm-copy usage, if you want to. > > > > Another option is to entirely attach your data from the source VM to the > > backup VM using qvm-block, which should be faster as it doesn't involve > > copy operations between VMs. See e.g [2] for that method. > > > > I'd also recommend to > > a) use software you trust for backups. > > b) use encrypted containers (e.g. dm-crypt) for backups unless you > > completely trust your cloud provider (I certainly don't). > > > > [1] https://www.qubes-os.org/doc/rpc-policy/ > > [2] https://github.com/3hhh/blib/blob/master/lib/os/qubes4/dom0#L955 > > > > You can also orchestrate the backups from dom0 using 'qvm-run'. This > gets rid of any need to set rpc policies or other sidestepping of > interactive prompts. For example: > > qvm-run -u root -p vault 'cryptsetup luksOpen /home/user/backup.img > backup --key-file key.dat && mount /dev/mapper/backup /mnt/backup' > > qvm-run -u root -p vault 'cp -au /home/user/Documents /mnt/backup && > umount /mnt/backup && cryptsetup luksClose backup' > > qvm-run -u root -p vault 'cat /home/user/backup.img' | qvm-run -p > cloudvm 'ssh u...@dest.com "cat >backup.img"' > > The above opens a LUKS encrypted container (disk image file), updates > the files within it using 'cp -au', then unmounts and closes the > container. Finally, it pipes the container img file through ssh to the > destination system. > > Initial setup of the container looks like (in vault vm): > > truncate -s 50M backup.img # Size is 50 megabytes > cryptsetup luksFormat backup.img > cryptsetup luksOpen backup.img backup > mkfs.ext4 /dev/mapper/backup > cryptsetup luksClose backup > sudo mkdir /mnt/backup > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > Thank you for the detailed instructions! I executed them until the SSH piping. What should I enter as u...@dest.com? I assume user@ ? But I get connection refused. In the firewall documentation one can enable networking between two qubes with iptables. "qvm-ls -n" shows the IP of the cloudvm, but the vault does not have IP. -- 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/1990240931.127715.1559034250599%40ichabod.co-bxl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Android-studio - more
‐‐‐ Original Message ‐‐‐ May 27, 2019 11:54 PM, 'awokd' via qubes-users escreveu: > See this thread maybe, not sure if it covers Studio. > https://www.mail-archive.com/qubes-users@googlegroups.com/msg25022.html I'll read. B -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/z75Rq1En4BXsE6wP2lfL3PMSvK41H-ZvraGwKJC6gu5Xc1JyYUGgYAVMs9Kv_59YtcwBIqvbSVTDWtkFt-GVXzTnnwxim_pmq6wzbY3Z6Is%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kernel 4.19.43 breaks sys-whonix too?
drok...@gmail.com wrote on 5/28/19 1:54 AM: On Monday, May 27, 2019 at 6:32:20 PM UTC-7, bm-2ctjsegdfzqngqw...@bitmessage.ch wrote: Interestingly, this apparently problematic 4.19.43 kernel did not break my Dom0 or Fedora-29, but instead, broke sys-whonix: I can connect through any chain of net-vms to clearnet, including through debian-9 VMs with 4.19.43. However, I could not get out to the internet via sys-whonix, until selecting an older kernel in sys-whonix itself. I'm not sure if that issue has been noted yet. A further twist is that updates via tor to onion repos still worked with the bad kernel in sys-whonix. It was only non-update traffic that could not make it through sys-whonix. This all happens with 4.19.43 in Dom0, and with kernel-latest (5-something) in Dom0, which had no impact on the issue. Whonix updating/working fine here. Maybe try creating a new sys-whonix2 VM from the template, and switch to it. Try 4.19.46-3 (in current-testing right now). I'm running it and tested debian-9, fedora-29, and whonix-ws through sys-whonix with no problems. -- 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/562bb56f-a107-f7b6-53b7-1bbe311bb84e%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Unable to upgrade Debian and whonix templates
Bryan Travers wrote on 5/28/19 9:56 AM: https://www.qubes-os.org/doc/installation-guide/#qubes-401-warning Thank you. Bryan On May 27, 2019, at 9:23 PM, awokd wrote: sahara090...@gmail.com wrote on 5/27/19 9:51 PM: Utilizing the code posted on the QubesOS website under “Warning”, I am unable to execute these upgrades. Sometimes they say the VM name is too long, other times it says it can’t find the name of the upgrade. getting frustrated and tried several times from different internet connections, always with the same result. Please link to the Warning to which you're referring. Thanks. CC'ing the qubes-users group back in. That way if people run into the same problem as you, they can search and find the solution here. Anyways, not sure why you're experiencing trouble there. Did you scroll all the way to the right? Another way to accomplish the same procedure is to run "sudo qubes-dom0-update" in a dom0 terminal, then after a reboot use the Update widget (sun like icon up by the clock) to update the 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/ccaad5ba-343e-43b7-092a-7038e8253eea%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] sys-usb not showing up for attached USB
haaber wrote on 5/28/19 1:43 AM: I experience (linked or not) a similar pb: all qvm-device (block/usb.etc) operations are quitted by "ERROR: Got empty response from qubesd.". Can I restart this service (since it runs apparently badly). Need I to reboot? I always reboot when I get that error since it leaves other Qubes services in an indeterminate state, and I'm not certain just restarting the qubesd service is enough. -- 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/7426ff82-3a8f-5e1b-9037-13a7676bebfe%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Openbsd HVM - Network Issues
Re Qubes 4.0. I have a openbsdVM but am unable to connect to internet. I'm using ip adresses from qubes manager i.e ip=10.137.0.28 netmask=255.255.255.255 gateway=10.137.0.6 dns=10.139.1.1 & 10.139.1.2. I'm able to ping 10.137.0.28 and 10.137.0.6 but unable to ping say google.com. I've tried without success copying the output from the command "ifconfig" & "route show" - maybe someone can give me advice on how to post the output to this forum? -- 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/65c31e6d8bcbb9f5cba72837d5c0cfc8%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Openbsd HVM - Network Issues
ronp...@riseup.net wrote on 5/28/19 11:57 AM: Re Qubes 4.0. I have a openbsdVM but am unable to connect to internet. I'm using ip adresses from qubes manager i.e ip=10.137.0.28 netmask=255.255.255.255 gateway=10.137.0.6 dns=10.139.1.1 & 10.139.1.2. I'm able to ping 10.137.0.28 and 10.137.0.6 but unable to ping say google.com. I've tried without success copying the output from the command "ifconfig" & "route show" - maybe someone can give me advice on how to post the output to this forum? Try making your netmask 255.255.255.0. You need to have Qubes Tools running for clipboard integration, so you might only be able to post screenshots if necessary. -- 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/b9764d3a-f661-f3a7-7c69-6606232aff0e%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q4.0 - LVM Thin Pool volumes - lsblk returns very large (256kb) MIN-IO and DISC-GRAN values
On Saturday, May 25, 2019 at 8:50:57 PM UTC-4, unman wrote: > Docs also say that where a thin pool is used primarily for thin > provisioning a larger value is optional. Did you mean to say "optimal" or did the docs really say that larger cluster sizes are optional? In any case, I think the docs I read had a bit of a hedge: they stated a larger value is better for performance, but a smaller value may be better for heavy COW usage. > This isnt a Qubes choice - it's Fedora, (and, I think, dependent on the > size of the pool.) Sure. Sounds like a lot of folks around here want to get out from under the thumb of Big Red. :P Brendan PS - opened three new issues... #5053 - Qubes Disk Widget - please inform about/alert on pool metadata space #5054 - LVM Pool metadata default size is too small #5055 - Add fstrim on shutdown of templates and template-based VMs -- 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/26ac4263-4508-48d0-9f7e-940631061349%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q4.0 - LVM Thin Pool volumes - lsblk returns very large (256kb) MIN-IO and DISC-GRAN values
On Saturday, May 25, 2019 at 2:28:13 PM UTC-4, Chris Laprise wrote: > I think the only _good_ way to deal with COW metadata expansion, since > its always related to data fragmentation, is to keep expanding it and > let system performance degrade accordingly. Yup. One could argue that the same solution could be *actively* applied to prevent running out of free space. :) My recollection is that my old Drobo used to do this (for free space, though presumably both). > This simply makes > de-fragmentation maintenance issue (defrag to shrink metadata and get > performance back). This is what Microsoft did with NTFS and it was the > right choice; clinging to fixed metadata sizes is merely a state of > denial that leads to peoples' disks suddenly becoming unusable. Lack of COW aside, NTFS's odd "separation plus mixing" of storage and metadata is fascinating. I mean, it works! And works pretty well! And is ancient! It *does* keep you on your toes, though, mitigating for forensics..."NTFS: oh, you have a small file? Well, I'll just store that over here in the metadata stream. You want to delete it? Sure, I'll mark it deleted. Erasing free space? go right ahead, I'll be over here waiting. Oh, it's still here? Well...better talk to Mr. Russinovich if you want to figure out how to really destroy that file..."* -Brendan * upon review, I read that in the Q voice, for maximum nerdiness. -- 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/61d159fe-b7e1-46a3-adba-1fa2c359bf26%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Openbsd HVM - Network Issues
On 2019-05-28 12:10, 'awokd' via qubes-users wrote: > ronp...@riseup.net wrote on 5/28/19 11:57 AM: >> Re Qubes 4.0. >> I have a openbsdVM but am unable to connect to internet. I'm using ip >> adresses from qubes manager i.e ip=10.137.0.28 netmask=255.255.255.255 >> gateway=10.137.0.6 dns=10.139.1.1 & 10.139.1.2. >> I'm able to ping 10.137.0.28 and 10.137.0.6 but unable to ping say >> google.com. >> >> I've tried without success copying the output from the command >> "ifconfig" & "route show" - maybe someone can give me advice on how to >> post the output to this forum? >> > Try making your netmask 255.255.255.0. You need to have Qubes Tools > running for clipboard integration, so you might only be able to post > screenshots if necessary. Thanks for your prompt reply. I have tried netmask 255.255.255.0 - but no success. As you suggested, attached is a screenshot of the command "ifconfig" -- 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/daa0c029a6cbd858a68062f7bc4741f0%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Device showing up in Qubes sys-usb terminal but not devices icon, and attach error in dom0
On Monday, May 27, 2019 at 8:05:07 PM UTC-4, awokd wrote: > Stumpy wrote on 5/27/19 4:09 PM: > > I am trying to use an onlykey U2F but have run into some issues like it > > showing up in dom0 and sys-usb but seems like i cant use it. > > > > in sys-usb: > > [user@sys-usb ~]$ lsusb | grep Only > > Bus 004 Device 010: ID 1d50:60fc OpenMoko, Inc. OnlyKey Two-factor > > Authentication and Password Solution > > > > and in Dom0: > > [ralph@dom0 ~]$ qvm-usb | grep ONLY ; sudo qvm-usb a sys-usb sys-usb:42 > > sys-usb:4-2 CRYPTOTRUST_ONLYKEY_346etc > > Device attach failed: > > [ralph@dom0 ~]$ > > > > I decided to go with the chrome app but even though sys-usb seems to see > > the onlykey I cant seem to attach it to the chrome appvm i made? > > > If you are using a custom template for your Chrome AppVM, don't forget > to install the necessary qubes-usb package in it. Also: 1) Is it a composite USB device (multiple services on a single endpoint, not a hub). 2) Is one or more service based on the HID interface and possibly blocked as it is seen as a keyboard? Similar issues occur with yubikeys, I believe there are documents that may help on the qubes-os.org site related to making yubikeys work. Brendan -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bd282497-0342-45e3-95d0-7d7cb1ac4a81%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Openbsd HVM - Network Issues
ronp...@riseup.net: On 2019-05-28 12:10, 'awokd' via qubes-users wrote: ronp...@riseup.net wrote on 5/28/19 11:57 AM: Re Qubes 4.0. I have a openbsdVM but am unable to connect to internet. I'm using ip adresses from qubes manager i.e ip=10.137.0.28 netmask=255.255.255.255 gateway=10.137.0.6 dns=10.139.1.1 & 10.139.1.2. I'm able to ping 10.137.0.28 and 10.137.0.6 but unable to ping say google.com. I've tried without success copying the output from the command "ifconfig" & "route show" - maybe someone can give me advice on how to post the output to this forum? Try making your netmask 255.255.255.0. You need to have Qubes Tools running for clipboard integration, so you might only be able to post screenshots if necessary. Thanks for your prompt reply. I have tried netmask 255.255.255.0 - but no success. As you suggested, attached is a screenshot of the command "ifconfig" Screenshot looks fine. "Route show" says your default route is to 10.137.0.6? Maybe reboot the HVM for good luck, if you haven't since the subnet mask update. Seems like you're almost there since you can ping 10.137.0.6. -- 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/062c3712-867b-4cb8-d23a-db6bb3de4c43%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to automate cloud backups of trusted vault files?
> > From: David Hobach > Sent: Tue May 28 10:11:18 CEST 2019 > To: Side Realiq , > Subject: Re: [qubes-users] How to automate cloud backups of trusted vault > files? > > > > > On 5/27/19 3:05 PM, David Hobach wrote: > > > > > > On 5/27/19 12:52 PM, 'Side Realiq' via qubes-users wrote: > >> How to automate backups of files from a very trusted vault to the > >> cloud? What are some best practices for that? > >> > >> My current issue is that the files in the trusted vault do not have > >> internet connection, so the cloud backup software should not be > >> running in the vault, and needs to run in a separate "backup" internet > >> connected qube. But I don't know how I can automate copying the files > >> from the vault to the backup qube. The qvm-copy command requires > >> manual choice of the target VM, which is not automated. > > > > This depends on your Qubes RPC policy, which you can manage with the > > /etc/qubes-rpc/policy files in dom0. Also see [1]. > > So you can automate qvm-copy usage, if you want to. > > > > Another option is to entirely attach your data from the source VM to the > > backup VM using qvm-block, which should be faster as it doesn't involve > > copy operations between VMs. See e.g [2] for that method. > > > > I'd also recommend to > > a) use software you trust for backups. > > b) use encrypted containers (e.g. dm-crypt) for backups unless you > > completely trust your cloud provider (I certainly don't). > > > > [1] https://www.qubes-os.org/doc/rpc-policy/ > > [2] https://github.com/3hhh/blib/blob/master/lib/os/qubes4/dom0#L955 > > I had received another few private questions about this that I'd like to > respond to: > > 1. "You mentioned "use encrypted containers" when backups are made they > are encrypted correct? How about AppVMs, are they encrypted by default?" > > The default backups made by Qubes OS are encrypted and should be the > overall preferred way of doing backups. > > Since the OP was asking about only backing up dedicated files rather > than the entire AppVM (what the Qubes OS backup does), he'd have to > implement the encryption part himself. > > It might make also sense to put the data meant to be backed up inside a > dedicated VM and then use the default backup mechanism with your cloud > provider. Of course you'd have to mount the cloud provider file system > inside your backup VM first. > > Personally, I don't use the default mechanism for speed reasons - my > internet connection is too slow to push 100+ GB over it for every > backup. sparsebak might help here [3], but is not official yet. > > [3] https://github.com/tasket/sparsebak > > 2. "For option 2) the function b_dom0_attachVMDisk attaches "the entire > private disk image (private.img) of the source VM to the target VM". In > my vault there is a folder with the encrypted files, and another with > decrypted files and I don't want to expose the decrpyted files to > another VM. Can I attach only a specified folder (with the encrypted > files) to another VM? If yes how?" > > You can only attach devices to other VMs with qvm-block. So you'd have > to put your file inside a loop device, which you could then attach to > the backup VM. If "encrypted files" means a dm-crypt container, you can > map the decrypted data from your AppVM to your backup VM (cryptsetup > creates a /dev/mapper/something device after decryption, which you can > then use with qvm-block). > > I'll also release some software in a month or so to simplify dm-crypt > usage with Qubes OS. > > Alternatively you could separate the files you'd like to backup from > those you don't by using different VMs for them. Thank you! 2) I created a loop device in the vault VM, attached it to the cloudVM. I can see that the files which were in the vaultVM loop device are also accessible from the cloudVM. I created a new file in the vaultVM loop device, but the file didn't show up the attached folder in the cloudVM. Why is that and how can I make them sync? -- 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/1278756646.143966.1559050620561%40ichabod.co-bxl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Is it safe to update dom0 now?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > > > 'awokd' via qubes-users: scurge1tl: > I am reading the threads related to the issues with the > dom0 update. Do I understand it properly that now it is > safe to update the dom0 and the mentioned issues are not > spawning anymore? > > Should I better backup my qubes before proceeding to the > USB? Yes, the newer branch of kernel has been temporarily pulled from updates. It is still a good idea to do a backup before major updates. > > > > How would one know if an update is a major one? Or you mean every > dom0 update should be considered to be major? > > > Kernel updates and/or Xen updates for dom0 are considered major. > > Basically, you should update all other qubes as you normally > would, but when it says there are dom0 updates, check them out > first. > >> From Qubes Manager: > > dom0 -> Upgrade qube > > It will download updates, but before installing, will show you > what they are, and ask if you want to install. If you see kernel > and/or xen updates, it's always a good idea of cancelling the > update, and do a backup first. And check here for problems too. > Is it a good practice to backup the Templates as well? It is a bit large, but I guess if I would like to restore the qubes from backup, I will need to have the templates installed to make it successful, right? Or is it enough to backup the important VMs only? -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEExlmPb5HoPUTt+CQT44JZDAWK6UwFAlztPj1fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2 NTk4RjZGOTFFODNENDRFREY4MjQxM0UzODI1OTBDMDU4QUU5NEMACgkQ44JZDAWK 6UzA4RAAkHhfH8OhsxNa2OKpdgwM3//zAePxInV4tK3hknm54czDRP9jnZwXLnyS E6ni8pneWu+3pja16o97ivr1gzJiz7lY+TmMH+uyAs8xUKQytl9qaTlw6B89jg8r 3C3i495QrHGRerWS9rD5B3l47Ukhc/wS+oEBTwgdWpm2KB0pz0I6QI2Oc+zPruGQ QTK3QwCBAfX6QxOW5pJhHFG0wj49xuhdbseSfia0MjhobNSEsMJgPAAVs5ABvm27 BM/2g5xU5RvfP6iToh5htLfWQflSzwxmpNXVY+OFyGunPTj80zAW7iTtI7BIi+KN 0Y8jIkw8Gopxrc4qa9y5uZNXtmAZmbIify35/Bglms+DW5+wFOhxNUfSpsq9YkFt f5nyxa0qpnb81CzWRlmoiOqZuA3sLg1ACs4TEhw3tIsqaOmqn+xgI6SNkycNCrRG xOEHQTWe9iZA6aWtX7nnAElcqljZCVdmiMNyM1K2MqtfH7EQ+P4DRO0nNe/KY3NN QCZizlY1uvHyoVqoOpoMaOmVpefg3qpshDLt6gu02TJNm3JRd1wwY7RcLqvp5PoF 1+5r+TTsf2ncPIXUsYJJ/Fka7i3Rmr3R9ofyRUsRL6gr+0iRvgU1ZdsDEXgY1RHs OqOyyxotG6NTnP7SQQJi08HOJWgANIqVeqQzDA74Zm+vKXyrTvA= =47bF -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/e68dcedf-49c7-9342-be2e-120a0a2cbebb%40cock.li. For more options, visit https://groups.google.com/d/optout. 0xC1F4E83AF470A4ED.asc Description: application/pgp-keys
Re: [qubes-users] Openbsd HVM - Network Issues
On 2019-05-28 13:15, 'awokd' via qubes-users wrote: > ronp...@riseup.net: >> On 2019-05-28 12:10, 'awokd' via qubes-users wrote: >>> ronp...@riseup.net wrote on 5/28/19 11:57 AM: Re Qubes 4.0. I have a openbsdVM but am unable to connect to internet. I'm using ip adresses from qubes manager i.e ip=10.137.0.28 netmask=255.255.255.255 gateway=10.137.0.6 dns=10.139.1.1 & 10.139.1.2. I'm able to ping 10.137.0.28 and 10.137.0.6 but unable to ping say google.com. I've tried without success copying the output from the command "ifconfig" & "route show" - maybe someone can give me advice on how to post the output to this forum? >>> Try making your netmask 255.255.255.0. You need to have Qubes Tools >>> running for clipboard integration, so you might only be able to post >>> screenshots if necessary. >> >> Thanks for your prompt reply. I have tried netmask 255.255.255.0 - but >> no success. >> As you suggested, attached is a screenshot of the command "ifconfig" >> > Screenshot looks fine. "Route show" says your default route is to > 10.137.0.6? Maybe reboot the HVM for good luck, if you haven't since > the subnet mask update. Seems like you're almost there since you can > ping 10.137.0.6. As you suggested, I rebooted but it complained about netmask 255.255.255.0 and refused to ping anything. I tried reverting to netmask 255.255.255.255 and now cannot ping 10.137.06 I'm adjusting these settings in /etc/hostname.xnf0 which now reads inet 10.137.0.28 255.255.255.255 10.137.0.6 Does that look right to you? After changing these setting i run "sh /etc/netstart" Which I think is equivalent to rebooting? -- 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/79f1b3e3c32bce483a35aa1ff7d167e8%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Updating Fedora-template
Hello forum. I am new to Qubes and Fedora... is there an equivalent to the Debian 'apt-get update upgrade' ? Thank's a lot for your feedback! Joe -- 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/20190528153202.0E2012010D%40smtp.hushmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Updating Fedora-template
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 josefh.maier via qubes-users: > Hello forum. I am new to Qubes and Fedora... is there an equivalent > to the Debian 'apt-get update upgrade' ? Thank's a lot for your > feedback! > > Joe > apt-get of debian is equal to dnf in fedora -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEExlmPb5HoPUTt+CQT44JZDAWK6UwFAlztVaVfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2 NTk4RjZGOTFFODNENDRFREY4MjQxM0UzODI1OTBDMDU4QUU5NEMACgkQ44JZDAWK 6UxgJA//SfVfi/QgI4lz6BWRuHTzc1QuQVpT4hLpNQdOHmpFWw19toHVu4Lrq+Jp GQzUhfDBjcv98fpXJFzSoHhqDqbvwkJNIyG0JQRV95XxoaBPlW3HiZ9FBbIW0GHY LtsbXXrefI5OLC9O4E8QPUoPatBRvIpJkDxOjwp+9b5AsOnGMA3p5Q2D6eOkqYkQ xAQKUdms2pwbYXIyAMzbXUJQlFMdm9seH2++RLL0MjbaMI6IO/8iq4GtpyFYabhy 2k1v/be1KQeYYioFI9bkL+ukD0T0RxCq9P54v33a91qJyPPs9HQZxzMeXBXhn5QQ mqeR6nlW00rBUk9/syudJYIRbzVD7iD0knDWgKmgyXFqrPEfzXzM5GJl8HsLtSQ9 dGXut6XWUZwWwQyTAu5g3u74+feJ1M/ppL981/aQpM+TlSJ1M+s63n+TZVGddHuB NFCEzk85sz/SUvfWA7VqrKO5sU36PkTBhdFvHwtTXIWLN7DV/ptulImi0yGKkZTU SX6WGHkheQQgWI3rmCxfHTT8axWXEtXRxoNUUH868otN6BHee0FVhPPTWqxOqiBB 0mT8UABm0VTryFkKzvpanrYL9Ddm4POTzsJOFG08U/MCh0apFwHCGfoihfVA1iE9 y839ExqvoFXJHS2YAoXE2XFg0AS4DmqQlOl+JwHDREBLhy9o9ds= =MGnb -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/594ed318-d404-0445-4adc-d7277e250d85%40cock.li. For more options, visit https://groups.google.com/d/optout. 0xC1F4E83AF470A4ED.asc Description: application/pgp-keys
[qubes-users] R4.0.1 Thinkpad e590 igfx graphic issues uefi, legacy not installable
I installed qubes 4.0.1 multiple times and still can not get the graphics to work properly I have the slow screen rendering issues from the intel graphics troubleshooting page and also had the iommu=noigfx and alpha...=1 flags enabled by default I thought it would go away after updating but i can not update dom0 I tried installing it in legacy mode but it crashes with an ACPI error. I really want this and bought a thinkpad just for qubes. What can i do? -- 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/74c9915e-60db-4017-9a25-1f7e55d391f3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] X230 vs Purism - real world attack probability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 taii...@gmx.com: > On 05/21/2019 09:52 AM, scurge1tl wrote: >> I have a question related to the decision about what laptop is >> the better option for Qubes usage, from the security point of >> view, in the real world. >> >> The question is related to the IME on Intel, PSP on AMD and >> other Hardware holes. I took these laptop examples to sample the >> differences somehow. >> >> Pose the non-existent micro controllers updates, like in case of >> X230 with IME disabled and corebooted, which doesn't but get >> these updates anymore, > > What updates? who told you that? What micro controllers? I heard that many times during discussions. I am not a programmer so I have to rely on others to evaluate the situation. > >> higher risk than only partial disabling of the IME by Purism >> which still but gets the micro controllers updates? Or is it a >> vice versa? >> >> If I would like to have a strong security position, in case of >> the laptop Hardware with Qubes, and would decide in between the >> two, which variant will be more prone to the real world attacks? >> What attack vectors are available in both cases? For example, is >> one of the cases more resistant to the remote exploitation. Is >> one of the options forcing an attacker more to execute an attack >> with physical access than the other option? >> > > pur.company is junk, they are an incredibly dishonest company that > sells "coreboot open firmware librem" machines that have a hw init > process that is entirely performed via the Intel FSP binary blob. > > The x230 is far more free than anything pur.company could sell > you, freeing intel fsp won't happen due to how difficult it would > be without documentation and how long it would take and it is both > impossible and illegal to free Intel ME. > > Illegal? Yes - ME/PSP is a DRM mechanism and bypassing them is > illegal in the usa where they are based. > > But since the 230 still has an ME abit more nerfed than the > purijunk you should get a G505S which has no ME/PSP and is the most > free laptop option. You mention G505S. Can it run Qubes without issues? > > Pur.junk = me kernel+init code run (not disabled), HW init 100% > blobbed - performed via Intel FSP X230 = me init code runs (not > disabled), HW init is open source G505S = No ME/PSP, CPU/RAM hw > init is open source, graphics/power mgmt requires blob but IOMMU > prevents them from messing with stuff. - the most free Can the G505S be bought in the setup you mentioned, with CPU/RAM HW init opensource and so on, or it is needed to hack it myself? What is the performance of the X230 versus G505S? Seems that X230 and G505S have 1366x768. Is there full HD option? Can the Ram be upgraded to 16GB on both? > > pur.company lies by claiming their ME is "disabled" when the kernel > and init code still run. > > > I don't want to say their name as they send someone out of the > woodwork to defend them and waste my time every time someone > mentions them in a negative light they go and start claiming that > they are "doing their best" - whereas various other much newer > companies are actually selling owner controlled libre firmware > trustworthy general computing hardware proving their claims of > "doing our best" to be bullshit. > > If you want more info see my other posts as I have made many of > them re: pur.company or laptop/desktop/workstation selections. > -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEExlmPb5HoPUTt+CQT44JZDAWK6UwFAlztYvBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2 NTk4RjZGOTFFODNENDRFREY4MjQxM0UzODI1OTBDMDU4QUU5NEMACgkQ44JZDAWK 6Uy78A/+N+BL/lLBodnYBR7yfrOisHvUtxMacQ2A/m6+4OAsZSRyGVN+qxSOg269 LZgxwZfaJuWZuuhPGuLftY7j7Vz4zopgPjlcVQ0UR01HD9jx16lXD3E2mvGxxuSr gwOY1FlrknV15qFl/V1HvGXKXpqOCKOyPUjdjSyGpB8kc0lvjAaC1KDj09G6CzXF scp98rOLFYbvIairEfWuiIvwjTmfwyTxNQRrG7hYomiE5EzDslPT4Owpoky9RGzj T3ICHJq2pq/8GqgnX7DarxkPRlKt7VNMg6ZdfoCkeN+zqty0T2WMvre77kgAlykQ HMh+hdkrGztFapM1lA1PBifxNhznxDcsICEzl5khPyey3sZYkA1HVZ37Z+SVMYyB XtbFc+vFx8l0uEhyXlJkotgxg+1liguReK3KCn1t75CpUsiVrQI2dtxC7Ns3SjmI H/Hlg30Ju4KV9emb0icNHwtv9HhE9huOnFzKS3KjGHTn+GrS0ubzQXfvRmfrAFbC Kwz6OYQP6VsX4FwJek6UwS+rfTyHi50Uef/QvxKqN3OyukonVfGFzB+l7EWZthpd U63IdtVD0dcHag27qh65ayPXwTTLLHxpa+52eHxnxI+19u2RT5XErhdEDBzL9UDC kghFEw/Rmt1sGaG93+vRRVFpyph1JWnyyQEbnji/FAx72ALv754= =YmLb -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/a16d0794-a892-0a75-16f9-6bf20aa2fb29%40cock.li. For more options, visit https://groups.google.com/d/optout. 0xC1F4E83AF470A4ED.asc Description: application/pgp-keys
[qubes-users] dsa-4371-update
Good day Qubes community, I created a debian-10 template and I cannot use the qubes-manager to start the update because of the dsa-4371-update that is looking for a either 8.0 or 9.0 in the /etc/debian-version and I have a 10.0. How do I fix this? Thanks! Dominique -- 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/d4b61177-5760-4950-b3b2-64fbd2ae7042%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] R4.0.1 Thinkpad e590 igfx graphic issues uefi, legacy not installable
The newest kernel updatev(a day old) solved that problem for me. -- 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/831f58b0-c3d0-43e9-9479-7dbc05dddaef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: dsa-4371-update
Hello again, Found it by myself. I modified the script located in Dom0:/usr/libexec/qubes-manager/dsa-4371-update I added those lines: 10.*) codename="buster" pkg="libapt-pkg5.0" fixed_version="1.8.1" ;; Seems to be working fine for now!!! Any comments? Thanks On Tuesday, May 28, 2019 at 12:36:29 PM UTC-4, Dominique St-Pierre Boucher wrote: > Good day Qubes community, > > I created a debian-10 template and I cannot use the qubes-manager to start > the update because of the dsa-4371-update that is looking for a either 8.0 or > 9.0 in the /etc/debian-version and I have a 10.0. > > How do I fix this? > > Thanks! > > Dominique -- 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/50ddd851-c162-4a4e-b45d-007bc2b463f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] R4.0.1 Thinkpad e590 igfx graphic issues uefi, legacy not installable
Yes i have just seen your post and it did it for me as well :) FINALLY haha -- 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/0cde0aed-d46e-4a1c-bc1c-593d355079b8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Is it safe to update dom0 now?
scurge1tl wrote on 5/28/19 1:57 PM: Is it a good practice to backup the Templates as well? It is a bit large, but I guess if I would like to restore the qubes from backup, I will need to have the templates installed to make it successful, right? Or is it enough to backup the important VMs only? You don't exactly need to backup templates, but it can make recovery easier if you have heavily customized them. If you're only using templates that come with Qubes, the only difference compared to newly installed ones are updates. -- 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/befdc04c-3bac-f951-edbb-42025c5284d7%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Openbsd HVM - Network Issues
ronp...@riseup.net wrote on 5/28/19 2:29 PM: As you suggested, I rebooted but it complained about netmask 255.255.255.0 and refused to ping anything. I tried reverting to netmask 255.255.255.255 and now cannot ping 10.137.06 I'm adjusting these settings in /etc/hostname.xnf0 which now reads inet 10.137.0.28 255.255.255.255 10.137.0.6 Does that look right to you? After changing these setting i run "sh /etc/netstart" Which I think is equivalent to rebooting? Sorry, you've exceeded my minimal knowledge of BSD already. All HVM networking works the same, so I don't get why it's not here. I know some people have been able to get OpenBSD working; try searching this mailing list if you haven't yet or hopefully one of them will chime in. -- 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/f6faa962-c220-8de8-334b-f9273516523c%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
[qubes-users] whonix tor browser noscript button missing?
Hello Qubes Community, Has anyone noticed the blue/white noscript S button is missing since a recent whonix-torbrowser update? AFAIK this is needed use javascript in whonix. Anyone notice this or have a workaround? thx! -m0ssy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c70e49c8-7755-1df1-db2d-703a67787ef5%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] whonix tor browser noscript button missing?
mossy: > Hello Qubes Community, > > Has anyone noticed the blue/white noscript S button is missing since a > recent whonix-torbrowser update? AFAIK this is needed use javascript in > whonix. > > Anyone notice this or have a workaround? > > thx! > > -m0ssy > See https://trac.torproject.org/projects/tor/ticket/30600 . It's a pretty contentious issue, with Tor Browser devs closing as WONTFIX because they plan to introduce a new permissions UI sometime in the future. The NoScript widget still exists, and in fact its use is apparently still necessary for some sites to work, but you'll have to manually add the widget back to the toolbar (Settings button > Customize... > Right-click NoScript > Add to Toolbar). -- 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/f921a240-bfee-ca49-800f-525a7e7009e5%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: WARNING: don't update qubes, will break your install
for the record from the github qubes-bot said The package kernel-4.19.46-3.pvops.qubes has been pushed to the r4.0 testing repository for dom0. To test this update, please install it with the following command: sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing I did a dom0 update but haven't rebooted yet, I am at uptime of 10 days, shall I install over the top of the last dom0 update with the above ??? personally I don't even backup 1x/month, but then I am not creating very many files locally those are in the Vault , and rarely do I add anything to it I can't recall the last dom0 reinstall , nice thing is I can fail on the Templates and just reinstall those akin to borking a computer OS, without the risk to my local files as they live in the AppVMs :) -- 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/9dd30c6d-6761-a06b-f941-223c49bfe694%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: WARNING: don't update qubes, will break your install
On 5/26/19 1:32 AM, drokmed-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: I just noticed on the Fedora forums they released Fedora 30 today. Qubes runs Fedora 29, so I don't know if today's updates had anything to do with f30, but it might be related. Checking to see if anyone else on fedora forums has similar issue as mine. Are you saying you think your Fedora-29 template caused your dom0 domain to fail ? afaik the Qubes Fedora-29 template is not going to auto update to Fedora-30like with $dnf upgrade or something -- 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/e48de006-2a47-aed8-0078-4cd3475c44e0%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Updating Fedora-template
On 5/28/19 3:32 PM, josefh.maier via qubes-users wrote: Hello forum. I am new to Qubes and Fedora... is there an equivalent to the Debian 'apt-get update upgrade' ? Thank's a lot for your feedback! Joe for debian it's $ sudo apt-get update && apt-get dist-upgrade for fedora seems to be $sudo dnf update && sudo dnf upgrade but I am just at qubes 'kludge' level as to what is upgraded in both , though suppose could find the answer somewherez -- 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/9c4d117b-7e31-9fe4-b848-6fae623baacc%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: WARNING: don't update qubes, will break your install
On Tuesday, May 28, 2019 at 11:37:07 AM UTC-7, Jon deps wrote: > for the record from the github > > > qubes-bot said > > The package kernel-4.19.46-3.pvops.qubes has been pushed to the r4.0 > testing repository for dom0. > To test this update, please install it with the following command: > > sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing > > > I did a dom0 update but haven't rebooted yet, I am at uptime of 10 > days, shall I install over the top of the last dom0 update with > the above ??? > > > > > personally I don't even backup 1x/month, but then I am not creating very > many files locally > > those are in the Vault , and rarely do I add anything to it > > I can't recall the last dom0 reinstall , nice thing is I can fail on > the Templates and just reinstall those akin to borking a computer > OS, without the risk to my local files as they live in the AppVMs :) I see the new kernel is back in the dom0 repository, same name/version, no idea if it's a fix or the original. I spent the whole weekend getting my laptop working again, not ready to break it again. I'll hold off a few days on this one. Work to do. -- 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/2d887804-8f97-47cf-8701-94e21fe487ec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kernel 4.19.43 breaks sys-whonix too?
On Tue, 28 May 2019 10:56:30 + "'awokd' via qubes-users" wrote: > drok...@gmail.com wrote on 5/28/19 1:54 AM: > > On Monday, May 27, 2019 at 6:32:20 PM UTC-7, > > bm-2ctjsegdfzqngqw...@bitmessage.ch wrote: > >> Interestingly, this apparently problematic 4.19.43 kernel did not > >> break my Dom0 or Fedora-29, but instead, broke sys-whonix: I can > >> connect through any chain of net-vms to clearnet, including > >> through debian-9 VMs with 4.19.43. However, I could not get out to > >> the internet via sys-whonix, until selecting an older kernel in > >> sys-whonix itself. I'm not sure if that issue has been noted yet. > >> A further twist is that updates via tor to onion repos still > >> worked with the bad kernel in sys-whonix. It was only non-update > >> traffic that could not make it through sys-whonix. This all > >> happens with 4.19.43 in Dom0, and with kernel-latest (5-something) > >> in Dom0, which had no impact on the issue. > > > > Whonix updating/working fine here. Maybe try creating a new > > sys-whonix2 VM from the template, and switch to it. Strange, I could update just fine, and the sys-whonix connected to tor internally just fine, but VMs connecting through it had issues. The same was true when I made a new sys-whonix2 on the same kernel (not older ones). > Try 4.19.46-3 (in current-testing right now). I'm running it and > tested debian-9, fedora-29, and whonix-ws through sys-whonix with no > problems. Will have to figure out how to grab just this from testing and try, 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/A09AB2E5-B979-40CE-9223-51159FB7F928%40mail.bitmessage.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to automate cloud backups of trusted vault files?
On 5/28/19 5:04 AM, Side Realiq wrote: From: Chris Laprise Sent: Mon May 27 19:58:35 CEST 2019 To: David Hobach , Side Realiq , Subject: Re: [qubes-users] How to automate cloud backups of trusted vault files? On 5/27/19 9:05 AM, David Hobach wrote: On 5/27/19 12:52 PM, 'Side Realiq' via qubes-users wrote: How to automate backups of files from a very trusted vault to the cloud? What are some best practices for that? My current issue is that the files in the trusted vault do not have internet connection, so the cloud backup software should not be running in the vault, and needs to run in a separate "backup" internet connected qube. But I don't know how I can automate copying the files from the vault to the backup qube. The qvm-copy command requires manual choice of the target VM, which is not automated. This depends on your Qubes RPC policy, which you can manage with the /etc/qubes-rpc/policy files in dom0. Also see [1]. So you can automate qvm-copy usage, if you want to. Another option is to entirely attach your data from the source VM to the backup VM using qvm-block, which should be faster as it doesn't involve copy operations between VMs. See e.g [2] for that method. I'd also recommend to a) use software you trust for backups. b) use encrypted containers (e.g. dm-crypt) for backups unless you completely trust your cloud provider (I certainly don't). [1] https://www.qubes-os.org/doc/rpc-policy/ [2] https://github.com/3hhh/blib/blob/master/lib/os/qubes4/dom0#L955 You can also orchestrate the backups from dom0 using 'qvm-run'. This gets rid of any need to set rpc policies or other sidestepping of interactive prompts. For example: qvm-run -u root -p vault 'cryptsetup luksOpen /home/user/backup.img backup --key-file key.dat && mount /dev/mapper/backup /mnt/backup' qvm-run -u root -p vault 'cp -au /home/user/Documents /mnt/backup && umount /mnt/backup && cryptsetup luksClose backup' qvm-run -u root -p vault 'cat /home/user/backup.img' | qvm-run -p cloudvm 'ssh u...@dest.com "cat >backup.img"' The above opens a LUKS encrypted container (disk image file), updates the files within it using 'cp -au', then unmounts and closes the container. Finally, it pipes the container img file through ssh to the destination system. Initial setup of the container looks like (in vault vm): truncate -s 50M backup.img # Size is 50 megabytes cryptsetup luksFormat backup.img cryptsetup luksOpen backup.img backup mkfs.ext4 /dev/mapper/backup cryptsetup luksClose backup sudo mkdir /mnt/backup -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 Thank you for the detailed instructions! I executed them until the SSH piping. What should I enter as u...@dest.com? I assume user@ ? But I get connection refused. In the firewall documentation one can enable networking between two qubes with iptables. "qvm-ls -n" shows the IP of the cloudvm, but the vault does not have IP. There should be no need to adjust the Qubes firewall. The ssh command and u...@dest.com is just an example of a network/cloud protocol and destination address. You can choose whatever cloud destination suits you as long as you have an account with them. If they don't support ssh, you would have to substitute the ssh command with something else, such as 'aws'. Also, please see my next reply... -- 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/9bc75d39-fa2c-63c5-82c5-9f5087ac26a7%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to automate cloud backups of trusted vault files?
On 5/28/19 9:37 AM, 'Side Realiq' via qubes-users wrote: From: David Hobach Sent: Tue May 28 10:11:18 CEST 2019 To: Side Realiq , Subject: Re: [qubes-users] How to automate cloud backups of trusted vault files? On 5/27/19 3:05 PM, David Hobach wrote: On 5/27/19 12:52 PM, 'Side Realiq' via qubes-users wrote: How to automate backups of files from a very trusted vault to the cloud? What are some best practices for that? My current issue is that the files in the trusted vault do not have internet connection, so the cloud backup software should not be running in the vault, and needs to run in a separate "backup" internet connected qube. But I don't know how I can automate copying the files from the vault to the backup qube. The qvm-copy command requires manual choice of the target VM, which is not automated. This depends on your Qubes RPC policy, which you can manage with the /etc/qubes-rpc/policy files in dom0. Also see [1]. So you can automate qvm-copy usage, if you want to. Another option is to entirely attach your data from the source VM to the backup VM using qvm-block, which should be faster as it doesn't involve copy operations between VMs. See e.g [2] for that method. I'd also recommend to a) use software you trust for backups. b) use encrypted containers (e.g. dm-crypt) for backups unless you completely trust your cloud provider (I certainly don't). [1] https://www.qubes-os.org/doc/rpc-policy/ [2] https://github.com/3hhh/blib/blob/master/lib/os/qubes4/dom0#L955 I had received another few private questions about this that I'd like to respond to: 1. "You mentioned "use encrypted containers" when backups are made they are encrypted correct? How about AppVMs, are they encrypted by default?" The default backups made by Qubes OS are encrypted and should be the overall preferred way of doing backups. Since the OP was asking about only backing up dedicated files rather than the entire AppVM (what the Qubes OS backup does), he'd have to implement the encryption part himself. It might make also sense to put the data meant to be backed up inside a dedicated VM and then use the default backup mechanism with your cloud provider. Of course you'd have to mount the cloud provider file system inside your backup VM first. Personally, I don't use the default mechanism for speed reasons - my internet connection is too slow to push 100+ GB over it for every backup. sparsebak might help here [3], but is not official yet. [3] https://github.com/tasket/sparsebak 2. "For option 2) the function b_dom0_attachVMDisk attaches "the entire private disk image (private.img) of the source VM to the target VM". In my vault there is a folder with the encrypted files, and another with decrypted files and I don't want to expose the decrpyted files to another VM. Can I attach only a specified folder (with the encrypted files) to another VM? If yes how?" You can only attach devices to other VMs with qvm-block. So you'd have to put your file inside a loop device, which you could then attach to the backup VM. If "encrypted files" means a dm-crypt container, you can map the decrypted data from your AppVM to your backup VM (cryptsetup creates a /dev/mapper/something device after decryption, which you can then use with qvm-block). I'll also release some software in a month or so to simplify dm-crypt usage with Qubes OS. Alternatively you could separate the files you'd like to backup from those you don't by using different VMs for them. Thank you! 2) I created a loop device in the vault VM, attached it to the cloudVM. I can see that the files which were in the vaultVM loop device are also accessible from the cloudVM. I created a new file in the vaultVM loop device, but the file didn't show up the attached folder in the cloudVM. Why is that and how can I make them sync? If the security of vaultVM matters to you at all, don't do it this way. As I mentioned in my other response, encryption must first be applied. Since you're not well acquainted with the specifics, I'd suggest dropping the requirement to backup individual folders and instead using a passphrase with Qubes backup to backup the vaultvm to the backupvm, then use whatever file transfer software your cloud provider requires in the backupvm. -- 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/63e53e10-62b1-06bb-5a49-6f9b79d8c6eb%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kernel 4.19.43 breaks sys-whonix too?
bm-2ctjsegdfzqngqwuqjswro6jrwlc9b3...@bitmessage.ch wrote on 5/28/19 7:45 PM: Will have to figure out how to grab just this from testing and try, thanks! sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing kernel kernel-qubes-vm --best --allowerasing (Had it in my history buffer anyways!) -- 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/56b3552f-17d1-1d04-2ddf-faff696c34b3%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q4.0 - LVM Thin Pool volumes - lsblk returns very large (256kb) MIN-IO and DISC-GRAN values
On 5/28/19 8:42 AM, brendan.h...@gmail.com wrote: On Saturday, May 25, 2019 at 2:28:13 PM UTC-4, Chris Laprise wrote: I think the only _good_ way to deal with COW metadata expansion, since its always related to data fragmentation, is to keep expanding it and let system performance degrade accordingly. Yup. One could argue that the same solution could be *actively* applied to prevent running out of free space. :) My recollection is that my old Drobo used to do this (for free space, though presumably both). It would not be too presumptuous for Qubes to define thin lvm metadata as being in the same class as, say, filesystem metadata and let the system consume available vg space as needed. The best way to start this process is to lay down a rule saying you should only create/use one thin pool per volume group on a Qubes system. If the vg is dedicated to housing the one pool, then the gnarly questions around competing for storage space disappear. There is already an implicit policy that the user has to keep their eye on overall used space in the pool because of over-provisioning. Just extend that policy to 'volume group' and you can keep expanding tmeta automatically. The best possible (or at least better) implementation of this is to have a hook in lvm block layer itself that can briefly halt file operations while tmeta is expanded. This simply makes de-fragmentation maintenance issue (defrag to shrink metadata and get performance back). This is what Microsoft did with NTFS and it was the right choice; clinging to fixed metadata sizes is merely a state of denial that leads to peoples' disks suddenly becoming unusable. Lack of COW aside, NTFS's odd "separation plus mixing" of storage and metadata is fascinating. I mean, it works! And works pretty well! And is ancient! In my view, NTFS has "COW++". Shouldn't we in Unix land change our terminology and start calling the combination of COW and snapshots shadow copy? :) It *does* keep you on your toes, though, mitigating for forensics..."NTFS: oh, you have a small file? Well, I'll just store that over here in the metadata stream. You want to delete it? Sure, I'll mark it deleted. Erasing free space? go right ahead, I'll be over here waiting. Oh, it's still here? Well...better talk to Mr. Russinovich if you want to figure out how to really destroy that file..."* -Brendan * upon review, I read that in the Q voice, for maximum nerdiness. -- 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/f6618f4d-e9f4-fac7-3ba6-136369e73305%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup while VMs are running??
On 5/28/19 2:51 AM, Claudio Chinicz wrote: Hi All, I make few backups because I fear doing backups while using my VMs, specially Windows 10 and Linux Mint HVMs. So, I do it once in a while, when I have have some free time and can spen not using the computer while it prepares the backups, after having shut down the VMs. All the discussion about updates breaking Qubes makes me wonder I should do backups more often. Is it possible to do backups of HVMs and VMs in general while using them? I'm afraid I may have an issue when restoring. If you installed Qubes with the disk/storage defaults, which uses LVM snapshots – or if you manually set it to install with Btrfs – then its safe to backup while VMs are running. The backup will simply use the snapshot from the last time the VM was shut down. OTOH, if you manually changed the Qubes install to use Ext4 filesystem, there might be a problem in that case. The disk usage widget in the system tray will tell you what kind of storage system your Qubes is using; if you used the default LVM it will say "lvm" with the usage stats to the right. -- 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/af598aec-0a29-4f3c-65c2-2216bb16e88e%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: real and virtual storage usage by qubes
On 5/27/19 8:18 PM, 'awokd' via qubes-users wrote: Jon deps wrote on 5/27/19 4:58 PM: On 5/27/19 8:23 AM, Eva Star wrote: Hello, Qubes Manager show virtual storage per qube? If qube storage increase on day then decreased again Qubes Manager will still show maximum? How to make it show real size? And how to check real storage usage per qube? Thanks I believe once you increase it, you can't decrease it, all you can do it make a new smaller qube and qvm-move the files over ; hence I don't think of it as virtual storage If you run fstrim -av inside the qube, it's supposed to release unused space back to the thin filesystem. Keep in mind this will probably cause the volume to consume more LVM metadata or 'tmeta'. The filesystem probably avoids sending trim/discard for smaller chunks to avoid filling up the tmeta area (at which point the storage pool becomes unusable). Thread https://groups.google.com/d/msgid/qubes-users/44f1ae64-2da1-480f-aa30-98c5f22653ba%40googlegroups.com -- 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/2c4e0b4a-d360-2867-cb26-78ac7428519b%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup while VMs are running??
On Mon, May 27, 2019 at 11:51:02PM -0700, Claudio Chinicz wrote: > Hi All, > > I make few backups because I fear doing backups while using my VMs, specially > Windows 10 and Linux Mint HVMs. So, I do it once in a while, when I have have > some free time and can spen not using the computer while it prepares the > backups, after having shut down the VMs. > > All the discussion about updates breaking Qubes makes me wonder I should do > backups more often. > > Is it possible to do backups of HVMs and VMs in general while using them? I'm > afraid I may have an issue when restoring. > > Thanks in advance, > Claudio > If you backup a running qube with Qubes backup, it will backup the state before you started it. May or may not be what you want. You can use file backups to capture anything since qube started. btrfs will let you snapshot running systems. -- 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/20190528232916.4jmlhu4le4vl2u5x%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Openbsd HVM - Network Issues
On Tue, May 28, 2019 at 07:29:31AM -0700, ronp...@riseup.net wrote: > On 2019-05-28 13:15, 'awokd' via qubes-users wrote: > > ronp...@riseup.net: > >> On 2019-05-28 12:10, 'awokd' via qubes-users wrote: > >>> ronp...@riseup.net wrote on 5/28/19 11:57 AM: > Re Qubes 4.0. > I have a openbsdVM but am unable to connect to internet. I'm using ip > adresses from qubes manager i.e ip=10.137.0.28 netmask=255.255.255.255 > gateway=10.137.0.6 dns=10.139.1.1 & 10.139.1.2. > I'm able to ping 10.137.0.28 and 10.137.0.6 but unable to ping say > google.com. > > I've tried without success copying the output from the command > "ifconfig" & "route show" - maybe someone can give me advice on how to > post the output to this forum? > > >>> Try making your netmask 255.255.255.0. You need to have Qubes Tools > >>> running for clipboard integration, so you might only be able to post > >>> screenshots if necessary. > >> > >> Thanks for your prompt reply. I have tried netmask 255.255.255.0 - but > >> no success. > >> As you suggested, attached is a screenshot of the command "ifconfig" > >> > > Screenshot looks fine. "Route show" says your default route is to > > 10.137.0.6? Maybe reboot the HVM for good luck, if you haven't since > > the subnet mask update. Seems like you're almost there since you can > > ping 10.137.0.6. > As you suggested, I rebooted but it complained about netmask > 255.255.255.0 and refused to ping anything. > I tried reverting to netmask 255.255.255.255 and now cannot ping > 10.137.06 > I'm adjusting these settings in /etc/hostname.xnf0 which now reads inet > 10.137.0.28 255.255.255.255 10.137.0.6 Does that look right to you? > After changing these setting i run "sh /etc/netstart" Which I think is > equivalent to rebooting? man hostname.if man myname Keep the 255.255.255.0 netmask Put 10.137.0.6 in /etc/mygate -- 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/20190528233641.jcmea2kmb3kyyqlj%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Updating Fedora-template
On Tue, May 28, 2019 at 06:43:36PM +, Jon deps wrote: > On 5/28/19 3:32 PM, josefh.maier via qubes-users wrote: > > Hello forum. > > I am new to Qubes and Fedora... is there an equivalent to the Debian > > 'apt-get update upgrade' ? > > Thank's a lot for your feedback! > > > > Joe > > > > for debian it's > $ sudo apt-get update && apt-get dist-upgrade > > for fedora seems to be > > $sudo dnf update && sudo dnf upgrade > > but I am just at qubes 'kludge' level as to what is upgraded in both , > though suppose could find the answer somewherez You can just use 'dnf update' In dom0 use 'qubes-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/20190528234352.zo3gkrq2a5cs77qu%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Recover from /boot wipe
May 27, 2019, 7:46 PM by awokd: > Connor Schunk wrote on 5/26/19 11:30 PM: > >> After installing Qubes, I attempted to install Windows as a dualboot option. >> >> Unfortunately, I didn't check to make sure windows wouldn't wipe my boot >> partitions, so now I have nothing under /boot other than the Linux .imgs in >> the LVM partition. >> >> Is there a way to recover the old install? I installed Qubes onto a >> different partition to get the /boot files back, what lines do I need to >> change to point to the correct encrypted LVM partition? >> > Probably safest bet is to boot Qubes Rescue mode from USB (or some other live > image), then mount your encrypted partition and copy out data you want to > keep. > Would it be possible to extract the qubes from the partition you think? Or at least some configs? -- 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/Lg-tHVN--3-1%40schunkc.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] whonix tor browser noscript button missing?
g80vmgm...@riseup.net: > mossy: >> Hello Qubes Community, >> >> Has anyone noticed the blue/white noscript S button is missing since a >> recent whonix-torbrowser update? AFAIK this is needed use javascript in >> whonix. >> >> Anyone notice this or have a workaround? >> >> thx! >> >> -m0ssy >> > > See https://trac.torproject.org/projects/tor/ticket/30600 . > > It's a pretty contentious issue, with Tor Browser devs closing as > WONTFIX because they plan to introduce a new permissions UI sometime in > the future. > > The NoScript widget still exists, and in fact its use is apparently > still necessary for some sites to work, but you'll have to manually add > the widget back to the toolbar (Settings button > Customize... > > Right-click NoScript > Add to Toolbar). > Hey, thanks! So really just annoying in Qubes to have to re-enable the widget in (whonix) disp-VMs. Appreciate the link to the tor project issue. -m0ssy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/10576ca2-3a69-8362-ea4a-c9a2159a8ae8%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] fedora-30 template update, problem with fuse
https://i.imgur.com/EdJIHgq.png How to fix? 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/6273d00b-8eb9-4562-8d24-2867b10ba3af%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qubes-tunnel service fails in VPN ProxyVM
I set up a VPN gateway in a ProxyVM using the qubes-tunnel service, but the service fails after restarting the VM. journalctl -u qubes-tunnel shows the failure happening after: ... qtunnel-setup[663]: -su: notify-send: command not found ... systemd[1]: qubes-tunnel.service: Control process exited. code=exited status=127 the command: /usr/lib/qubes/qtunnel-setup --config worked fine, so I'm not sure what's going awry. fwiw, I had the same setup working in R3.2, but started from scratch in R4.0.1. I downloaded the github project and installed it in the template VM before completing the following instructions in the ProxyVM: https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service -- 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/3voGBReT1G57oqJvBCbSloJrWsuryNYAYKe7p2Kq0RaXllYqs5xHrmJhHMjtsl-Wol1ncidoA-akXsoFbWXFG5aPJpWRhsohXhypBHSFYOE%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: whonix tor browser noscript button missing?
On 5/29/19 12:02 AM, mossy wrote: g80vmgmsqw-sgozh3hwpm2stnjn9+b...@public.gmane.org: mossy: Hello Qubes Community, Has anyone noticed the blue/white noscript S button is missing since a recent whonix-torbrowser update? AFAIK this is needed use javascript in whonix. Anyone notice this or have a workaround? thx! -m0ssy See https://trac.torproject.org/projects/tor/ticket/30600 . It's a pretty contentious issue, with Tor Browser devs closing as WONTFIX because they plan to introduce a new permissions UI sometime in the future. The NoScript widget still exists, and in fact its use is apparently still necessary for some sites to work, but you'll have to manually add the widget back to the toolbar (Settings button > Customize... > Right-click NoScript > Add to Toolbar). Hey, thanks! So really just annoying in Qubes to have to re-enable the widget in (whonix) disp-VMs. Appreciate the link to the tor project issue. -m0ssy in 8.5 its still there -- 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/e79a507f-0d15-7350-5574-8894216d3016%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-tunnel service fails in VPN ProxyVM
On 5/28/19 8:44 PM, 'b17b7bdb' via qubes-users wrote: I set up a VPN gateway in a ProxyVM using the qubes-tunnel service, but the service fails after restarting the VM. journalctl -u qubes-tunnel shows the failure happening after: ... qtunnel-setup[663]: -su: notify-send: command not found ... systemd[1]: qubes-tunnel.service: Control process exited. code=exited status=127 the command: /usr/lib/qubes/qtunnel-setup --config worked fine, so I'm not sure what's going awry. fwiw, I had the same setup working in R3.2, but started from scratch in R4.0.1. I downloaded the github project and installed it in the template VM before completing the following instructions in the ProxyVM: https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service It seems like the notify-send command is missing in the templatevm. I recommend not using minimal templates, and for now avoid fedora-29 (fedora-28 and debian are OK). -- 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/cac7c57f-8353-b76c-a901-18d8dab39b18%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] auto-mount external storage
I would like a specific appVM (say "private") to auto-mount an encrypted container. So, the wanted behaviour is: I plug in a usb / hard drive, attach it to my appVM (private) and then see it opened and mounted in (say) /home/user/data without any further action, typing passwords etc. On std linux this would be done using a LUKS keyfile, and by editing /etc/crypttab and /etc/fstab/ Question: Where do I have to locate these files in qubes-os to have them survive a reboot? Do I need an extra template "just for that" ? Cheers! -- 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/4127d39a-9b79-1661-bce5-858a6755b9fd%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Dell XPS 15 9570 UEFI Issue
I had a problem with v4.0.1 hanging halfway through the install, but adding "mapbs=1 noexitboot=1" seems to have fixed the issue. Unfortunately, the system does not boot -- it does not see a bootable device. I tried following the UEFI troubleshooting article to no avail. Copying /boot/efi/EFI/qubes to /boot/efi/EFI/BOOT with all the accompanying instructions did not work. I did notice that the xen-*efi file was 0 length, so I also followed the instructions on adding the entries (with the correct file versions of course), but the last instruction talks about running the efibootmgr command, which doesn't run because there is no efivars kernel module. I personally hate UEFI, but these newer systems leave you no choice -- you CANNOT boot from an internal drive without it. Does anyone know how to resolve this? I have a nice and very expensive brick that I'd like to turn into a production system. Any help would be greatly appreciated. -- 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/e595613f-507c-455f-a6a7-ca941ecb2719%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Dell XPS 15 9570 UEFI Issue
I meant to say that the xen.cfg file was 0 length; not the efi file. -- 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/da465528-5450-4c5b-bf3d-3e0562a1f4eb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
