[qubes-users] Re: Well color me impressed (4.0.1-rc2 install on laptop and desktop)
On Thursday, December 20, 2018 at 9:11:34 PM UTC-8, John Smiley wrote: > I've been having head-banging issues with 4.0 and 4.0.1-rc1 ever since I > became a fledgling Qubes user a few weeks ago. I never did get Qubes working > well with Whonix 14 on the desktop. > > When 4.0.1-rc2 came out the other day, I made a new bootable USB stick with > it and replaced Ubuntu on my Thinkpad T480 with it. It booted and installed > without a hitch. Perfect first use impression (minus a point for nagging > about template updates that aren't there). > > Then I decided to do a reinstall (for the N thousanth time) on my X299-based > desktop. 4.0.1-rc2 fired right up. No problems whatsoever. It works like I > expected 4.0 and 4.0.1-rc1 to work. > > Then for the really impressive part. I have a Caldigit TS3 Plus that I like > to use to move all of the wire mess to it and have a single Thunderbolt3 wire > running from it to the T480. It provides lots of things but I use it for > power to my laptop (replacing the brick), Ethernet, Displayport for a second > monitor, and USB 3.1. After the 4.0.1-rc2 install went so well, I decided to > plug that bad boy in and watch Qubes fall to the ground writhing in agony. > > My expectations were not met. 4.0.1-rc2 handled it like a champ. I had to > do some minor fiddling with the display settings to get the second monitor > working via DP and after a bit of hunting around, I discovered that all I had > to do to get Ethernet working was to add the new Ethernet controller it saw > to sys-net. Shutdown the Whonix GW and sys-firewall, reboot sys-net, restart > sys-firewall and the Whonix GW, plug in my Ethernet cable and voila. It > works! > > Now the first question that comes to mind is, how much security did I throw > out the window when I plugged that Thunderbolt 3 hub in? Oh and one more thing. Everything installed with default settings. No fiddling with kernelopts to get the Debian-9 template to boot on the X299 desktop by setting noxsave. -- 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/bb11bb26-4f07-4772-a1cf-6699a08a48ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Well color me impressed (4.0.1-rc2 install on laptop and desktop)
I've been having head-banging issues with 4.0 and 4.0.1-rc1 ever since I became a fledgling Qubes user a few weeks ago. I never did get Qubes working well with Whonix 14 on the desktop. When 4.0.1-rc2 came out the other day, I made a new bootable USB stick with it and replaced Ubuntu on my Thinkpad T480 with it. It booted and installed without a hitch. Perfect first use impression (minus a point for nagging about template updates that aren't there). Then I decided to do a reinstall (for the N thousanth time) on my X299-based desktop. 4.0.1-rc2 fired right up. No problems whatsoever. It works like I expected 4.0 and 4.0.1-rc1 to work. Then for the really impressive part. I have a Caldigit TS3 Plus that I like to use to move all of the wire mess to it and have a single Thunderbolt3 wire running from it to the T480. It provides lots of things but I use it for power to my laptop (replacing the brick), Ethernet, Displayport for a second monitor, and USB 3.1. After the 4.0.1-rc2 install went so well, I decided to plug that bad boy in and watch Qubes fall to the ground writhing in agony. My expectations were not met. 4.0.1-rc2 handled it like a champ. I had to do some minor fiddling with the display settings to get the second monitor working via DP and after a bit of hunting around, I discovered that all I had to do to get Ethernet working was to add the new Ethernet controller it saw to sys-net. Shutdown the Whonix GW and sys-firewall, reboot sys-net, restart sys-firewall and the Whonix GW, plug in my Ethernet cable and voila. It works! Now the first question that comes to mind is, how much security did I throw out the window when I plugged that Thunderbolt 3 hub 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/41c3b812-0e84-43d2-956c-208a263f7e0a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: 4.0.1-RC2 Boot loop after install
I should have been clearer in indicating how far the boot process got: The text messages were displayed starting in the top left corner of the screen until the screen cleared and the Qubes Q-logo was displayed with a progress bar underneath. The boot process continued until the progress indicator was about 1/4 to 1/3 of the way across, then the screen went black and my computer starts to reboot. -- 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/39acbdd4-3aa5-48fc-b194-1a32c55f2153%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: 4.0.1-RC2 Boot loop after install
On Thursday, 20 December 2018 22:02:00 UTC-3:30, John Goold wrote: > Attached is screenshot, taken under my current OS, showing OS and hardware > info. > > After spending much too much time trying to track the problem down (using the > 4.0, 4.0.1-RC1 and 4.0.1-RC2 ISOs) I discovered why getting the installer to > run was failing... > > I had to unplug my external monitor (connected via an HDMI port). > > I was then able to boot the install DVD and install to an external USB (SSD) > drive (Seagate 2 TB). The install completed (supposedly successfully), but > attempts to boot from the USB drive fail. > > The boot process starts, with text being displayed starting in the top left > corner of the screen. It progresses to the point that the Qubes Q-logo is > displayed with a progress bar below it. The boot process continues until the > progress indicator is 1/4 to 1/3 of the way across, then the screen goes > black and my computer starts to reboot. > > I have searched the mailing list and have failed to find a solution (hours > spent doing this). A lot of people seem to end up in boot-loops, using > various hardware. > > The attached file shows the hardware. The following information about the > BIOS/Firmware may be relevant: > > * Legacy Boot is enabled > * Virtualization Technology is enabled > > During the install I setup a user account. I did not enable disk encryption > (I will leave that until after I can get Qubes to boot). > > Comment: This boot-loop problem (or similar boot-loop problems) seems to be a > major issue with installing Qubes 4.x. Each time I come across a posting > about it, there seem to be different suggestions (some of which work on the > particular hardware involved) and some of which do not. > > I believe that I tried R3.1 about a year or so ago and that it booted > alright. I cannot remember why I did not follow through on adopting Qubes (if > I could not get my external monitor working, that would be a deal-breaker). > > Suggestions would be appreciated. I will provide any additional information I > am capable of. -- 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/f777a7bb-685e-41b0-b9a6-22cb463de7db%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] 4.0.1-RC2 Boot loop after install
Attached is screenshot, taken under my current OS, showing OS and hardware info. After spending much too much time trying to track the problem down (using the 4.0, 4.0.1-RC1 and 4.0.1-RC2 ISOs) I discovered why getting the installer to run was failing... I had to unplug my external monitor (connected via an HDMI port). I was then able to boot the install DVD and install to an external USB (SSD) drive (Seagate 2 TB). The install completed (supposedly successfully), but attempts to boot from the USB drive fail. The boot process starts, with text being displayed starting in the top left corner of the screen. It progresses to a point, then the screen goes black and my computer starts to reboot. I have searched the mailing list and have failed to find a solution (hours spent doing this). A lot of people seem to end up in boot-loops, using various hardware. The attached file shows the hardware. The following information about the BIOS/Firmware may be relevant: * Legacy Boot is enabled * Virtualization Technology is enabled During the install I setup a user account. I did not enable disk encryption (I will leave that until after I can get Qubes to boot). Comment: This boot-loop problem (or similar boot-loop problems) seems to be a major issue with installing Qubes 4.x. Each time I come across a posting about it, there seem to be different suggestions (some of which work on the particular hardware involved) and some of which do not. I believe that I tried R3.1 about a year or so ago and that it booted alright. I cannot remember why I did not follow through on adopting Qubes (if I could not get my external monitor working, that would be a deal-breaker). Suggestions would be appreciated. I will provide any additional information I am capable of. -- 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/4464d0d4-2d10-4aad-a0f9-40fe67d99afc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fed-28 update error
On 20181220 at 14:53 -0500 Chris Laprise wrote:
> How stable is the CentOS 7 "testing" template? I'm so over Fedora,
> but need dnf for full compatibility with qubes-dom0-update.
It just self-destructed by upgrading x11-xorg*, see "[qubes-users]
updating CentOS-7 templates" - I guess I have to find
xorg-x11-server-{Xorg,common}-1.19.5 as Nick Darren wrote. Besides that it's
quite useful (but the arch template is more versatile). Fedora and plain Debian
have a sucking coefficient that rips fleas off dogs.
Achim
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/5f87fd65e58a1d9bd582f9772aa0aa0f6fcfc5e2.camel%40noses.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fed-28 update error
On 12/20/2018 09:49 AM, Steve Coleman wrote: On 12/19/18 6:39 PM, Andrew David Wong wrote: It's an upstream Fedora issue. For more info, see: https://github.com/QubesOS/qubes-issues/issues/4629 Yes, this is an upstream problem, which has been fixed in the "updates-testing" repo. I got bitten by this one in that hplip got removed, so I was unable to print anything, so I was forced to investigate. The temporary fix here should be to enable the "updates-testing" repo and reinstall the packages ntop hplip net-snmp-libs to force the correct dependancies to be evaluated. Since my installation was missing hplip I had to install, rather than reinstall, but that set of commands should look something like this: $ sudo dnf clean all $ sudo dnf reinstall --allowerasing --enablerepo=updates-testing hplip net-snmp-libs $ sudo dnf clean all $ sudo dnf update You may see ntop being removed as a dependent package, in which case you may need to reinstall it after the above is completed if you use it. Hopefully those two packages from testing were not full of bugs. I'll be testing that this afternoon after some meetings. Steve. How stable is the CentOS 7 "testing" template? I'm so over Fedora, but need dnf for full compatibility with qubes-dom0-update. -- 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/1a8bd0b7-332a-fadc-5dae-17067ea44908%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes-Vpn-support not connected. Please help me.
On 12/20/2018 02:11 PM, menoldst...@gmail.com wrote: Dec 20 20:49:08 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:49:08 2018 RESOLVE: Cannot resolve host address: fi.privateinternetaccess.com:1198 (Name or service not known) That's the problem. Did you test the connection as suggested in Step 2, before running install? Also, what is the difference between the old style and the new style men? -- 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/fe1e4b07-cffb-9508-73d9-50a24535c8b8%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Update to Qubes-scripts
* qubes4-multi-update Updates are now attempted for each specified VM even if some VMs experience update errors. Any VMs with errors are reported at the end. This allows an update process to be as complete as possible in less than ideal conditions. * findpref Can now search on 'None' empty fields, and no longer requires a searchvalue (in which case all values for requested pref are shown). * kde-color.sh Sets custom window border colors in a Qubes 4 KDE environment. Colors can be edited with RGB values, and the default palette goes well with both light _and_ dark window content. - Also should mention that my new (very fast!) incremental backup tool will be having its final alpha release probably in the next few days... https://github.com/tasket/sparsebak/tree/new3 ** Happy Holidays to everyone on this last day of Autumn! ** -- 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/3bc5c3bc-561e-d34c-768d-754adf448c80%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes-Vpn-support not connected. Please help me.
Hello, I am trying to configure Qubes-vpn-support https://github.com/tasket/Qubes-vpn-support/ , but I can not. Help. What do I need to do to complete the VPN setup? https://github.com/tasket/Qubes-vpn-support/ [user@VPN1 ~]$ systemctl status qubes-vpn-handler ● qubes-vpn-handler.service - VPN Client for Qubes proxyVM Loaded: loaded (/usr/lib/systemd/system/qubes-vpn-handler.service; enabled; v Drop-In: /usr/lib/systemd/system/qubes-vpn-handler.service.d └─00_example.conf Active: active (running) since Thu 2018-12-20 21:24:36 MSK; 6min ago Process: 2409 ExecStopPost=/usr/lib/qubes/qubes-vpn-setup --post-stop (code=ex Process: 2451 ExecStartPost=/usr/lib/qubes/qubes-vpn-setup --post-start (code= Process: 2416 ExecStartPre=/usr/lib/qubes/qubes-vpn-setup --pre-start (code=ex Process: 2412 ExecStartPre=/usr/lib/qubes/qubes-vpn-setup --check-firewall (co Main PID: 2450 (qubes-vpn-setup) Tasks: 2 (limit: 4915) CGroup: /system.slice/qubes-vpn-handler.service ├─2450 /bin/sh /usr/lib/qubes/qubes-vpn-setup --start-exec └─2455 /usr/sbin/openvpn --cd /rw/config/vpn/ --config /tmp/vpn-clien lines 1-14/14 (END) [user@VPN1 ~]$ journalctl -u qubes-vpn-handler -- Logs begin at Tue 2018-12-11 19:45:56 MSK, end at Thu 2018-12-20 21:30:47 MSK. -- Dec 20 20:47:46 VPN1 systemd[1]: Starting VPN Client for Qubes proxyVM... Dec 20 20:47:46 VPN1 qubes-vpn-setup[1014]: iptables: Bad rule (does a matching rule exist in that chain?). Dec 20 20:47:48 VPN1 qubes-vpn-setup[1014]: iptables: Bad rule (does a matching rule exist in that chain?). Dec 20 20:47:50 VPN1 qubes-vpn-setup[1014]: iptables: Bad rule (does a matching rule exist in that chain?). Dec 20 20:47:50 VPN1 qubes-vpn-setup[1014]: Error: Firewall rule(s) not enabled! Dec 20 20:47:50 VPN1 systemd[1]: qubes-vpn-handler.service: Control process exited, code=exited status=1 Dec 20 20:47:50 VPN1 systemd[1]: Failed to start VPN Client for Qubes proxyVM. Dec 20 20:47:50 VPN1 systemd[1]: qubes-vpn-handler.service: Unit entered failed state. Dec 20 20:47:51 VPN1 qubes-vpn-setup[1207]: STOP-ing network forwarding! Dec 20 20:47:50 VPN1 systemd[1]: qubes-vpn-handler.service: Failed with result 'exit-code'. Dec 20 20:48:01 VPN1 systemd[1]: qubes-vpn-handler.service: Service hold-off time over, scheduling restart. Dec 20 20:48:01 VPN1 systemd[1]: Stopped VPN Client for Qubes proxyVM. Dec 20 20:48:01 VPN1 systemd[1]: Starting VPN Client for Qubes proxyVM... Dec 20 20:48:01 VPN1 qubes-vpn-setup[1770]: iptables: Bad rule (does a matching rule exist in that chain?). Dec 20 20:48:04 VPN1 su[1858]: (to user) root on none Dec 20 20:48:10 VPN1 qubes-vpn-setup[2086]: START-ing network forwarding! Dec 20 20:48:10 VPN1 systemd[1]: Started VPN Client for Qubes proxyVM. Dec 20 20:48:10 VPN1 qubes-vpn-setup[2085]: EXEC /usr/sbin/openvpn --cd /rw/config/vpn/ --config /tmp/vpn-client.conf --verb 3 --mlock --ping 10 --ping-restart 42 --conne Dec 20 20:48:10 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:48:10 2018 OpenVPN 2.4.5 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD Dec 20 20:48:10 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:48:10 2018 library versions: OpenSSL 1.1.0g-fips 2 Nov 2017, LZO 2.08 Dec 20 20:48:10 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:48:10 2018 mlockall call succeeded Dec 20 20:48:10 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:48:10 2018 WARNING: you are using user/group/chroot/setcon without persist-tun -- this may cause restarts to fai Dec 20 20:48:10 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:48:10 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Dec 20 20:48:21 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:48:21 2018 RESOLVE: Cannot resolve host address: fi.privateinternetaccess.com:1198 (Name or service not known) Dec 20 20:48:31 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:48:31 2018 RESOLVE: Cannot resolve host address: fi.privateinternetaccess.com:1198 (Name or service not known) Dec 20 20:48:52 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:48:52 2018 RESOLVE: Cannot resolve host address: fi.privateinternetaccess.com:1198 (Name or service not known) Dec 20 20:49:08 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:49:08 2018 RESOLVE: Cannot resolve host address: fi.privateinternetaccess.com:1198 (Name or service not known) Dec 20 20:49:08 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:49:08 2018 Could not determine IPv4/IPv6 protocol Dec 20 20:49:08 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:49:08 2018 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay Dec 20 20:49:08 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:49:08 2018 SIGUSR1[soft,init_instance] received, process restarting Dec 20 20:49:08 VPN1 qubes-vpn-setup[2085]: Thu Dec 20 20:49:08 2018 Restart pause, 5 second(s) lines 1-32
Re: [qubes-users] Using an OnlyKey
> As I understood your setup for OnlyKey consists of two parts: first - make it > work as a keyboard, second - make TOTP work. I think I stuck on the first > one. I modified the file from Qubes docs and I able to attach a regular USB > keyboard - it works in any qubes. But when I insert the OnlyKey stick I see > it is discovered as a Teensyduino_Keyboard_RawHID_xxx but the LED indicator > on the stick doesn't work and it looks like it doesn't accept the PIN (or > even do anything). Does you LED work well for you? Any thoughts? When I was seeing no LED response I thought device is not working, but it turned out that OnlyKey itself works but just without LED indication. Here (https://groups.google.com/forum/#!topic/onlykey/-93A-9_SjAM) I found that the reason for not working LED might be a bit higher voltage (I'm on lenovo x1c6 btw). -- 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/30451b29-9461-48a9-914f-e36e2287fc05%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] receive updates
I thought this action was fix but it seem i still have to change all http to htpps in qubes 4.0.1-rc2 by running the bottom comand . Is that normal i still have to run these comand with this new fresh install ? thank you Qubes 4.0 Warning In new installations of Qubes 4.0, the following steps may need to be applied in dom0 and Fedora 26 TemplateVMs in order to receive updates (see #3737). Steps for dom0 updates: Open the Qubes Menu by clicking on the “Q” icon in the top-left corner of the screen. Select Terminal Emulator. In the window that opens, enter this command: sudo nano /etc/yum.repos.d/qubes-dom0.repo This opens the nano text editor. Change all four instances of http to https. Press CTRL+X, then Y, then ENTER to save changes and exit. Check for updates normally. Steps for Fedora 26 TemplateVM updates: Open the Qubes Menu by clicking on the “Q” icon in the top-left corner of the screen. Select Template: fedora-26, then fedora-26: Terminal. In the window that opens, enter the command for your version: [Qubes 3.2] sudo gedit /etc/yum.repos.d/qubes-r3.repo [Qubes 4.0] sudo gedit /etc/yum.repos.d/qubes-r4.repo This opens the gedit text editor in a window. Change all four instances of http to https. Click the “Save” button in the top-right corner of the window. Close the window. Check for updates normally. Shut down the TemplateVM. -- 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/3294f07f-31e2-4395-84d8-c92c8e392939%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Whonix error while updating
Just got the following Whonix 14 error. Seems like it downloaded the whole file then reported an error code anyway... _[0m _[1D_[0G 99% _[7m _[0m _[1D_[0G 100% _[7m Failed to download: https://dist.torproject.org/torbrowser/8.0.4/tor-browser-linux64-8.0.4_en-US.tar.xz Possible reasons: - The download server is down. - File size exceeded (endless data attack triggered). - Tor Browser Downloader (by Whonix developers) has been broken due to upstream changes. Recommendations: - Try again later. If the error persists it probably won't solve itself before the next update. - Check News: https://www.whonix.org/wiki/Stay_Tuned - Manually update: https://www.whonix.org/wiki/Manually_Updating_Tor_Browser (Debugging information: curl_status_message: [1] - [Unsupported protocol. This build of curl has no support for this protocol.]) INFO: Failing open. More info: https://www.whonix.org/wiki/Tor_Browser#tb-updater_postinst I also have an issue about the curl status display. It seems to be configured to ignore the TERM environment so when its in a qvm-run session it scrolls tons of un-escaped characters which is annoying. -- 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/4ba7e612-a834-b76f-440a-c25be9a03013%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] default-mgmt-dvm no longer hidden
I ran updates for dom0 this morning, I noticed that after the updates, the default-mgmt-dvm is no longer hidden. It is still marked internal, but not hidden. Is this the desired outcome of the latest dom0 updates? Ed -- 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/bbfc36c6-480c-4825-9e72-792326cee742%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes-vpn-support. PLEASE HELP ME!
On 12/20/2018 04:35 AM, menoldst...@gmail.com wrote: Hello, you can help set up https://github.com/tasket/Qubes-vpn-support/ Qubes-vpn-support #sorry my bad English I seem to have done everything according to the instructions, but when I enter systemctl status qubes-vpn-handler shows: ● qubes-vpn-handler.service - VPN Client for Qubes proxyVM Loaded: loaded (/usr/lib/systemd/system/qubes-vpn-handler.service; enabled; vendor preset: disabled) Drop-In: / usr / lib /systemd/system/qubes-vpn-handler.service.d 00─00_example.conf Active: activating (auto-restart) (Result: exit-code) since Wed 2018-12-19 22:02:50 MSK; 7s ago Process: 21996 ExecStopPost = / usr / lib / qubes / qubes-vpn-setup - post-stop (code = exited, status = 0 / SUCCESS) Process: 21992 ExecStartPost = / usr / lib / qubes / qubes-vpn -setup - post-start (code = exited, status = 0 / SUCCESS) Process: 21991 ExecStart = / usr / lib / qubes / qubes-vpn-setup - start-exec (code = exited, status = 1 / FAILURE ) Process: 21963 ExecStartPre = / usr / lib / qubes / qubes-vpn-setup --pre-start (code = exited, status = 0 / SUCCESS) Process: 21959 ExecStartPre = / usr / lib / qubes / qubes-vpn- setup --check-firewall (code = exited, status = 0 / SUCCESS) Main PID: 21991 (code = exited, status = 1 / FAILURE) A VPN-VM window constantly pops up on top: Ready to start link I also did not quite understand point 2 in the installation: Copy the VPN configuration files from your service provider to the proxyVM / rw / config / vpn folder, then copy or link the desired configuration to “vpn-client.conf”: cd / rw / config / vpn sudo unzip ~ / ovpn-configs-example.zip sudo ln -s US_East.ovpn vpn-client.conf I copied all the configuration files (France.ovpn, ca.rsa.2048.crt, crl.rsa.2048.pem), but what does it mean to associate the desired configuration with vpn-client.conf? After unpacking sudo unzip ~ / ovpn-configs-example.zip, I get a vpn-client.conf-example file. I understand that I need to rename its extension to .conf? Does it need to be edited? Forget the example file. As the instructions suggest, you need to run: cd /rw/config/vpn sudo ln -s France.ovpn vpn-client.conf -- 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/76edbf6f-b502-e221-3843-efc1383f1e04%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: updating CentOS-7 templates
So does anyone reported this issue to qubes-issues? -- 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/eff2de39-6598-4032-b5dd-b56a3babf53e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fed-28 update error
On 12/19/18 6:39 PM, Andrew David Wong wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/19/18 4:34 AM, qubes-...@tutanota.com wrote: Hi, I updated the dom0 and after I tried to update the Fed-28 template. I get following error: [user@fedora-28 ~]$ sudo dnf update Last metadata expiration check: 0:27:37 ago on Wed 19 Dec 2018 11:04:23 AM CET. Dependencies resolved. Problem 1: cannot install the best update candidate for package hplip-3.18.6-10.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by hplip-3.18.6-11.fc28.x86_64 Problem 2: cannot install the best update candidate for package hplip-libs-3.18.6-10.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by hplip-libs-3.18.6-11.fc28.x86_64 Problem 3: cannot install the best update candidate for package libsane-hpaio-3.18.6-10.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by libsane-hpaio-3.18.6-11.fc28.x86_64 Problem 4: package hplip-libs-3.18.6-10.fc28.x86_64 requires hplip-common(x86-64) = 3.18.6-10.fc28, but none of the providers can be installed - cannot install both hplip-common-3.18.6-11.fc28.x86_64 and hplip-common-3.18.6-10.fc28.x86_64 - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64 - cannot install the best update candidate for package hplip-common-3.18.6-10.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by hplip-libs-3.18.6-11.fc28.x86_64 Package Arch VersionRepository Size Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): hplip-common x86_643.18.6-11.fc28 updates110 k Skipping packages with broken dependencies: hplipx86_643.18.6-11.fc28 updates 16 M hplip-libs x86_643.18.6-11.fc28 updates204 k libsane-hpaiox86_643.18.6-11.fc28 updates127 k Transaction Summary Skip 4 Packages Nothing to do. Complete! *** When doing the --best --allowerasing I get this: [user@fedora-28 ~]$ sudo dnf --best --allowerasing update Last metadata expiration check: 0:28:55 ago on Wed 19 Dec 2018 11:04:23 AM CET. Error: Problem 1: cannot install the best update candidate for package libsane-hpaio-3.18.6-10.fc28.x86_64 - problem with installed package libsane-hpaio-3.18.6-10.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by libsane-hpaio-3.18.6-11.fc28.x86_64 Problem 2: cannot install the best update candidate for package hplip-libs-3.18.6-10.fc28.x86_64 - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by hplip-libs-3.18.6-11.fc28.x86_64 Problem 3: cannot install the best update candidate for package hplip-3.18.6-10.fc28.x86_64 - problem with installed package hplip-3.18.6-10.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by hplip-3.18.6-11.fc28.x86_64 * Any help appreciated. Thank you! It's an upstream Fedora issue. For more info, see: https://github.com/QubesOS/qubes-issues/issues/4629 Yes, this is an upstream problem, which has been fixed in the "updates-testing" repo. I got bitten by this one in that hplip got removed, so I was unable to print anything, so I was forced to investigate. The temporary fix here should be to enable the "updates-testing" repo and reinstall the packages ntop hplip net-snmp-libs to force the correct dependancies to be evaluated. Since my installation was missing hplip I had to install, rather than reinstall, but that set of commands should look something like this: $ sudo dnf clean all $ sudo dnf reinstall --allowerasing --enablerepo=updates-testing hplip net-snmp-libs $ sudo dnf clean all $ sudo dnf update You may see ntop being removed as a dependent package, in which case you may need to reinstall it after the above is completed if you use it. Hopefully those two packages from testing were not full of bugs. I'll be testing that this afternoon after some meetings. Steve. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwa1q4ACgkQ203TvDlQ MDAJBQ//elkdQlan7qFyKFzj2yV/WNAlpvHxkP6GGX3CUBNlWTe7snFKZjAZgZvy wJAorPxP0wngEdBGc9VVeQ1OYBb/DZQ6akBTtNYYmAxC+bDfS37RyIKpvFx7e22w yrj0+0iS0T80HtrvhGfAAvBy7jro8oHiFi2u+1MDwytCVqsk2+ZeFaFaOYpDH9Zd b5U2QpZrEdF2vckK/pBxQLWfOWgX/FildH1P7VGwKtatHArODJ4qb8GjlzswZCxk 0RDy/FCD2s7vDe3wn46zZSCBHty5XRZO2jkfMbc/pbNeie9Il87JxCNdKXcJ4bci
Re: [qubes-users] Where is Qubes' idea of private image size coming from?
On 20181218 at 23:53 + unman wrote: > On Tue, Dec 18, 2018 at 09:18:06PM +0100, Achim Patzner wrote: > > [ap@dom0 bin]$ qvm-ls --disk BuilderNAME STATE DISKPRIV- > > CURR PRIV-MAX PRIV-USED ROOT-CURR ROOT-MAX ROOT- > > USEDBuilder Halted 124948 124948 2048 6100% 0 > > 10240 0%[ap@dom0 bin]$ > > > > Before I start doing something stupid (like reporting a non-issue or > > shooting my own foot): Where is that 2GB PRIV-USED coming from and how > > do I correct it? The image file itself has a size of 128GB right now... > 6100% used. Impressive. I really like efficient data compression... > I'm not clear if you tried to extend first or checked the sizes first. I have to admit that I wanted to use the Qubes-Manager (GUI tools make people lazy...) and started scratching my head first (getting me to realize that just increasing the size might not be the wisest decision). > You can see the code in > /usr/lib/python3.5/site-packages/qubesadmin/tools > > PRIV-MAX comes from vm.volumes[private].size - it's strange that that > should be showing the default 2G size. It's really there. But I used qubes tools to grow the image and they usually register correctly what they did in the relevant databases. > Just to be safe I would backup anything you have on the BuilderVM. > What does qvm-volume info Builder:private show? size 2G (in bytes) usage 128GB (in bytes) > You could try then resizing with extend. ... without changing any stored data... Ok, now the information is matching reality. If this is happening again I'll open an issue. Or get a patent for my compression algorithm. Achim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5f938cf7f5a3eafd7323fbabed524950996188f0.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Updates Proxy questions and possible concern
On Thu, Dec 20, 2018 at 10:29:31AM +, mossy wrote: > unman: > > On Wed, Dec 19, 2018 at 11:06:25PM +, mossy wrote: > >> Hello all, > >> > >> I was looking to see if I could update an offline standalone VM, by > >> appending a line to `etc/qubes-rpc/policy/qubes.UpdatesProxy` and I now > >> have some questions. > >> > >> First, I noticed the lines: > >> > >> ~~~ > >> # Default rule for all TemplateVMs - direct the connection to sys-net > >> $type:TemplateVM $default allow,target=sys-net > >> ~~~ > >> > >> Q1) Is this correct? Shouldn't updates be directed to sys-firewall > >> instead of sys-net? Are all of our templates exposed to (untrusted) > >> sys-net? > >> > >> Hopefully I am wrong about this, but either way I'd appreciate if > >> someone could explain... > >> > >> Q2) If I want to update an offline standalone VM called `OfflineSA`, > >> what would be the proper syntax in > >> `etc/qubes-rpc/policy/qubes.UpdatesProxy`? I have tried each of the > >> following without success: > >> > >> OfflineSA $default allow,target=sys-net > >> OfflineSA $default allow,target=sys-firewall > >> OfflineSA allow,target=sys-net > >> OfflineSA allow,target=sys-firewall > >> $type:StandaloneVM $default allow,target=sys-net > >> $type:StandaloneVM $default allow,target=sys-firewall > >> > >> Q3) do I need to restart my whole qubes system for any new > >> `etc/qubes-rpc/policy/qubes.UpdatesProxy` rules to come into effect? > >> > >> Q4) can update proxies perhaps only be set via some $tag or $type? > >> > >> Thank you! > >> > >> -m0ssy > > > > Q1. Yes, the default is to use sys-net. You can change this if you wish. > > (I do) > > The update proxy has always been set to sys-net by default. > > The proxy used to filter traffic, but no longer does so. Again, I change > > this behaviour. > > > > Q2. OfflineSA $default allow,target=sys-net > > should work: the syntax is right. (You do have proxy configured in > > OfflineSA?) > > > > Q3. No - changes in those rules come in to play straight away. > > > > Q4. No, they can be set on an individual basis. > > > > thanks for your reply! I do not have proxy configured in OfflineSA -- I > don't see an option in qvm-prefs anymore (thought this was all now done > in rpc-policy as of qubes 4). Can you please point me to how to configure? > > -m0ssy > Hi m0ssy Have you installed qubes-core-agent in the standAlone? That will provide /usr/lib/qubes/update-proxy-configs and the qubes-rpc service. unman -- 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/20181220121514.vfwwn5ny4c7hcrhm%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Updates Proxy questions and possible concern
unman: > On Wed, Dec 19, 2018 at 11:06:25PM +, mossy wrote: >> Hello all, >> >> I was looking to see if I could update an offline standalone VM, by >> appending a line to `etc/qubes-rpc/policy/qubes.UpdatesProxy` and I now >> have some questions. >> >> First, I noticed the lines: >> >> ~~~ >> # Default rule for all TemplateVMs - direct the connection to sys-net >> $type:TemplateVM $default allow,target=sys-net >> ~~~ >> >> Q1) Is this correct? Shouldn't updates be directed to sys-firewall >> instead of sys-net? Are all of our templates exposed to (untrusted) >> sys-net? >> >> Hopefully I am wrong about this, but either way I'd appreciate if >> someone could explain... >> >> Q2) If I want to update an offline standalone VM called `OfflineSA`, >> what would be the proper syntax in >> `etc/qubes-rpc/policy/qubes.UpdatesProxy`? I have tried each of the >> following without success: >> >> OfflineSA $default allow,target=sys-net >> OfflineSA $default allow,target=sys-firewall >> OfflineSA allow,target=sys-net >> OfflineSA allow,target=sys-firewall >> $type:StandaloneVM $default allow,target=sys-net >> $type:StandaloneVM $default allow,target=sys-firewall >> >> Q3) do I need to restart my whole qubes system for any new >> `etc/qubes-rpc/policy/qubes.UpdatesProxy` rules to come into effect? >> >> Q4) can update proxies perhaps only be set via some $tag or $type? >> >> Thank you! >> >> -m0ssy > > Q1. Yes, the default is to use sys-net. You can change this if you wish. > (I do) > The update proxy has always been set to sys-net by default. > The proxy used to filter traffic, but no longer does so. Again, I change > this behaviour. > > Q2. OfflineSA $default allow,target=sys-net > should work: the syntax is right. (You do have proxy configured in > OfflineSA?) > > Q3. No - changes in those rules come in to play straight away. > > Q4. No, they can be set on an individual basis. > thanks for your reply! I do not have proxy configured in OfflineSA -- I don't see an option in qvm-prefs anymore (thought this was all now done in rpc-policy as of qubes 4). Can you please point me to how to configure? -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/9d4df88e-f5aa-3c31-1f96-93b4369c8baf%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Keyboard backlight color based on active qube
So, you have found an ancient UNIX command to be useful for fuzzy testing: cat. -- 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/dc89750e-b053-4924-8615-21a8d46b8d10%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes-vpn-support. PLEASE HELP ME!
Hello, you can help set up https://github.com/tasket/Qubes-vpn-support/ Qubes-vpn-support #sorry my bad English I seem to have done everything according to the instructions, but when I enter systemctl status qubes-vpn-handler shows: ● qubes-vpn-handler.service - VPN Client for Qubes proxyVM Loaded: loaded (/usr/lib/systemd/system/qubes-vpn-handler.service; enabled; vendor preset: disabled) Drop-In: / usr / lib /systemd/system/qubes-vpn-handler.service.d 00─00_example.conf Active: activating (auto-restart) (Result: exit-code) since Wed 2018-12-19 22:02:50 MSK; 7s ago Process: 21996 ExecStopPost = / usr / lib / qubes / qubes-vpn-setup - post-stop (code = exited, status = 0 / SUCCESS) Process: 21992 ExecStartPost = / usr / lib / qubes / qubes-vpn -setup - post-start (code = exited, status = 0 / SUCCESS) Process: 21991 ExecStart = / usr / lib / qubes / qubes-vpn-setup - start-exec (code = exited, status = 1 / FAILURE ) Process: 21963 ExecStartPre = / usr / lib / qubes / qubes-vpn-setup --pre-start (code = exited, status = 0 / SUCCESS) Process: 21959 ExecStartPre = / usr / lib / qubes / qubes-vpn- setup --check-firewall (code = exited, status = 0 / SUCCESS) Main PID: 21991 (code = exited, status = 1 / FAILURE) A VPN-VM window constantly pops up on top: Ready to start link I also did not quite understand point 2 in the installation: Copy the VPN configuration files from your service provider to the proxyVM / rw / config / vpn folder, then copy or link the desired configuration to “vpn-client.conf”: cd / rw / config / vpn sudo unzip ~ / ovpn-configs-example.zip sudo ln -s US_East.ovpn vpn-client.conf I copied all the configuration files (France.ovpn, ca.rsa.2048.crt, crl.rsa.2048.pem), but what does it mean to associate the desired configuration with vpn-client.conf? After unpacking sudo unzip ~ / ovpn-configs-example.zip, I get a vpn-client.conf-example file. I understand that I need to rename its extension to .conf? Does it need to be edited? -- 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/7a9ed30a-8d1f-4246-88e1-80a7f3bbca14%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
