Re: [qubes-users] Anyone gotten bitcoind to install via snapcraft on an AppVM?

2020-03-03 Thread qubenix
tetrahedra via qubes-users:
> On Thu, Feb 27, 2020 at 03:18:30PM +, tetrahedra via qubes-users wrote:
>> Current best solution for running bitcoind on an AppVM:
>> Download the binaries, run bitcoind as `user`
> 
> For future reference, the current Bitcoin-on-Qubes howtos appear to be
> here:
> https://github.com/qubenix/qubes-whonix-bitcoin
> 
> Comments for qubenix:
> - Some systems have limited disk space (e.g SSDs) so it may make sense  
> to run a pruned node

That's true, but using a pruned bitcoind will limit its usefulness as a
backend for other software (eg. electrum servers, block explorers). You
may be able to use it for a specific purpose (eg. joinmarket), but the
point of my guides is that you can keep adding new software that comes
out (eg. btcpayserver, lnd, c-lightning, esplora) and connect it to your
bitcoind VM without having to reindex the chain.

> - it would be really nice to use bind-dirs to avoid creating a second  
> Whonix WS templateVM (which takes up lots of disk space) --  
> unfortunately I haven't figured out how to create a new user and keep  
> that user persistent (see prior email)
> 

This is a good point. Unfortunately I don't have a lot of extra
time/motivation currently to make sweeping changes like that. That's why
my btcpayserver branch hasn't been worked on since November.

It's nice to know that someone somewhere is paying attention to work
I've done with these. Thank you for that.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

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


Re: [qubes-users] wasabi in qubes

2019-06-26 Thread qubenix
'awokd' via qubes-users:
> ehag...@gmail.com:
>> I wouild like to use wasbi in a whonix VM.
>>
>> Can any one tell me how to make it work step by step_

There's some discussion here:
https://forums.whonix.org/t/wasabi-wallet-in-whonix/7597.

Basically just download it, verify signature, run it, and change config
settings to use your gateway's ip for your tor host.

> 
> Assuming Wasabi is a cloud provider and assuming it has some Linux

Wasabi is a Bitcoin wallet that facilitates CoinJoins for users:
https://www.wasabiwallet.io/. It's a centralized, easy to use solution
for people that want to protect against some blockchain analysis.

> client (would be good if you provided more detail so people don't have
> to guess), the direct answer to your question as stated would be to
> install their client software into the whonix-ws-14 template. However,
> unless you've audited their software this could be a bad idea from an
> anonymity perspective as it may link your identity across all Whonix
> client sessions.
> 
> Safer option would be to clone whonix-ws-14 to a new template just for
> Wasabi use, install their software in it, then create an AppVM based on
> it networked to sys-whonix.
>

Don't need to install in a template. Just run a release in an AppVM.


-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/170dd2d4-9569-6aba-ec04-08688f68f60f%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Announcement: Qubes Tor onion services will no longer be maintained

2019-03-25 Thread qubenix
Andrew David Wong:
> Dear Qubes Community,
> 
> We regret to announce that the Qubes Tor onion services will no longer
> be maintained due to lack of resources. This includes all Qubes onion
> services, including the Qubes website onion mirror and the onion package
> repos.
> 
> We would like to thank the Whonix Project for generously maintaining
> these services for over a year. [1] Maintaining the Tor onion services
> requires labor, servers, and bandwidth. Unfortunately, none of these
> resources are available to the Qubes OS or Whonix projects in sufficient
> quantities to allow us to continue offering these services.
> 
> We recommend that users who currently rely on any Qubes onion addresses
> transition to the corresponding clearnet addresses immediately.
> 
> 
> [1] 
> https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/
> 
> This announcement is also available on the Qubes website:
> https://www.qubes-os.org/news/2019/03/24/tor-onion-services-no-longer-maintained/
> 
> 

Wow, very sad. May I ask why so many extra resources are needed? Can't
you just install tor on the system that hosts your clearnet repos?

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/6400d67e-63f0-339a-b19d-6bf111c86bf2%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-25 Thread qubenix
OGBaby:
> Hey Qubenix, I have an update for you and anyone curious. The MDB_BAD_TXN 
> error has been resolved. For anyone wondering this error most likely mean 
> your blockchain was interrupted during sync and is now corrupt. 
> 
> The solution advised by Monero channels is to delete the blockchain data 
> ("lmdb") amd resync. 
> 
> I was recommended to include the flag '--db-sync-mode=safe' to monerod upon 
> startup to protect against unexpected interruptions or reboots during sync.
> 
> You should be able to locate the blockchain within /home/user/.bitmonero/
> 
> Keep in mind .bitmonero is a hidden directory.
> 
> After the resync everything regarding the daemon seem to be in place and 
> running. I will repost the most recent logs and provide fresh ones as well. 
> 
> I am being redirected back here since that particular monerod error appear to 
> be resolved, there may be a minor issue with the separation setup of wallet 
> and daemon VMs. The lower-left Network Status is 'disconnected' and of course 
> "Wallet is not connected to daemon" is still visible above. 
> 
> If there is anything specific I should verify and confirm, I  would gladly 
> take a look. 
> 
> Thanks everyone
> 
> Monerod status (previous)
> https://pastebin.com/v95gn1aB
> 
> Monerod Bitmonero.log (previous)
> https://pastebin.com/3mzhuSHt
> 
> Monerod Status (fresh)
> https://pastebin.com/XwAy91dh
> 
> Monerod Bitmonero.log (fresh)
> https://pastebin.com/CHSHg9Zz
> 
> 
> Hopefully it's just something I'm overlooking.
> 

Your daemon issues seem solved, so that's a step in the right direction.
Can you come on irc to resolve this (either freenode or oftc)? I suspect
we're going to be doing a lot of back and forth to find out which step
in the guide wasn't completed correctly.

If you want to, you can go back through the guide first and pay special
attention that you have done the following correctly:

1. Set up qrexec policy (/etc/qubes-rpc/policy/whonix.monerod-mainnet)
in dom0. Guide section 1.4.
2. Set up qrexec file
(/rw/usrlocal/etc/qubes-rpc/whonix.monerod-mainnet) on the daemon vm.
Guide section 3.2.
3. Set up /rw/config/rc.local on wallet vm. Guide section 4.2.

If all of that is done correct, the gui is set to use a local node, and
you still have no connection then we will need to do a lot of back and
forth with running commands in vms and telling me the output.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/86c93f8b-5a4c-4c83-a521-79e708c54e6c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: How risky is GPU pass-through?

2018-12-25 Thread qubenix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Zrubi:
> On 12/23/18 9:34 PM, Demi M. Obenour wrote:
>> Someone I know is interested in using QubesOS.  However, they
>> are also a gamer: if they could not have a Windows VM with access
>> to a dedicated graphics card for use by games, then QubesOS is
>> not an option for them.
> 
> Short answer: Qubes OS is not an option for them.
> 

Why do you say that? If you search this list there are people that
successfully game on Win vm with gpu passthrough.

> 
> The risk part would come only after this feature exists in practice
> ;) Search back for the details.
> 
> 

I can't speak to the security risk from personal experience or
knowledge, but I found this:
https://security.stackexchange.com/questions/162122/gpu-passthrough-security/162175.

- -- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEElgluTKCHDxxbr33ZCdFZ4SQfnFQFAlwgMjdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2
MDk2RTRDQTA4NzBGMUM1QkFGN0REOTA5RDE1OUUxMjQxRjlDNTQACgkQCdFZ4SQf
nFR7IA//YE7rVNDmYFiXmIU9v7d7j9Bg3bPNSQ6wFnWNclylA3NSvzJ2k/uurcXW
HSz/7r3jDSnJgD6trVan8SMOLlVhU48Hz9FCOxrVagwU69Ch+70vEZplauDcbEC7
UKu3vTFaC5Gawu8EHSqeT97eYCjSqvc/K82g6Wlij9uYOp7juTpQXX9ekIYH4i94
2TI+ZEYCJ/IaoL12aNQbDz6TzR6lsQDnsUiEppd1hnCX/yQphVymRlFG4qBQsXUA
40cAiqSUvpoAchxiWuTS7o4wCblSgrYkHHNzBvX0i+8JhSVmiknloPb+rBZmUVrs
0AoS2cqW3ojKIDXdfQ5Yn27p9TSR9AkoGbNDN9hZSl0CQTjXDGKV/Lcdj9qSSy+X
+xOEJL63nYp94hofsDmZhg7EfcARA5C5JbLF0TzA2fyXlO7hgoX/SsCAv+KaDWhE
8B3Sq+sWH7MAfiJOK/UZN52Bi+I5hUsYsdXPTDSxqkhc6aOnYL8i9wi89gPZ4iVi
JTQ6Tzn87Y5fWeBnz10viMWyfj71rD1AktA9GM20zsw60jx+GcDwtxOHxQLWRTNb
vR1KuET9E+XaS4oEmTcNDACNj0ui+H7OgCRt64plfOttrc9FDtUXgTLMHypMx0bV
zNsV02DucRNWaFSpG6ZrXJMarqvC4NLihAFzhpo2QsGQSpTgiME=
=suwp
-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/174d9e11-0e0a-7924-b8f8-5339b138358f%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-16 Thread qubenix
OGBaby:
> The last line of the bitmonero.log says: ERROR blockchain 
> src/cryptonote_core/nlockchain.cpp:3728 Exception in 
> cleanup_handle_incoming_blocks:Failed to commit a transaction to the db: 
> MDB_BAD_TXN: Transaction must abort, has a child, or is invalid.
> 

That is a new issue or you are out of space again (I think I remember
seeing that in one of your original mails iirc).

Either way it's not specific to your setup or to Qubes. Best to check on
Monero channels (reddit, irc, etc).

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/33cd7193-a769-756c-7b71-cefce6f7b05c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-16 Thread qubenix
OGBaby:
> Great info!
> 
> I wasn't able to get 'torsocks ./monerod' running but found these options 
> browsing:
> 

Why or where would you intend to run these? The monerod daemon should be
running in the background as soon as the vm is started.

You should never interact with the daemon like this. You should use
`systemctl` to start/stop the daemon. You can check if the daemon is
running by running `sudo systemctl status monerod` or using `tail` on
the debug.log (I gave you instructions in a previous mail on that).

> 
> 1. 'DNS_PUBLIC=tcp torsocks monerod --p2p-bind-ip 127.0.0.1 --no-igd'
> 
> 2. 'DNS_PUBLIC=tcp TORSOCKS_ALLOW_INBOUND=1 torsocks monerod --p2p-bind-ip 
> 127.0.0.1 --no-igd'
> 

You don't need these. They're for setups not as well designed as Whonix,
or if you're offering a remote node onion service.

> I just wanted to run these by you or the qubes community to make sure I don't 
> accidently mess with any default settings. (specifically the p2p option which 
> we've removed from the systemd file).>
> 'torsocks monerod' or 'torsocks ./monerod' and the ones I found above all 
> attempt to resync the blockchain. Is this normal behavior? 
> 

As I said, don't run the daemon from the command line. `systemd` is
handling it already.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/1d3968dd-06cd-a0ed-863a-038756f0a32d%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-16 Thread qubenix
OGBaby:
> Wow, I had to reread a few materials first but It finally clicked. Security 
> is the sole scope of this method. I had meshed a couple concepts together 
> somewhere along the line. There's been a lot of learning (using 
> linux/terminal included).
> 
> I've managed to successfully download the entire blockchain. 
> 
> Just got the "You are now synchronized with the network. You may start 
> monero-wallet-cli." message via status. 
> 
> Monerod is running. The Height displays as "1727318/1727318 (100%) on 
> mainnet, not mining"
> 
> The log: 'sudo tail -f /home/monerod/.bitmonero/bitmonero.log': "Synced 
> 1727379/1727379 -- Synchronized Ok"
>

Congrats! You're well on your way.

> 
> Only 1 error: Torsocks. Specifically, "connection refused to Tor Socks (in 
> sock5_recv_connect_reply() at socks5.c.549)"
> 
> 
> P.S. Must I wrap 'monero-wallet-gui' with "torsocks"? This is what I'm doing 
> now.

No, only the daemon needs `torsocks`. The wallets (cli and gui) just
make a local connection to the daemon so no `torsocks` needed for them.

> 
> Created the wallet and made time to write down all keys & seed. Connected to 
> Local.
> 
> The GUI, I assume, will remain disconnected. You mentioned above that things 
> should be handled within the Daemon vm, would you mind filling me in? (i.e 
> confirming xmr recieved, sending xmr to address)

I'm not sure what you mean by "disconnected", the gui will connect to
the daemon to retrieve information about the state of the blockchain to
derive your balance. However, it will not connect to the internet
directly to help protect against remote attackers.

I haven't used the gui in about a year, but if you look at left sidebar
there should be some indication that you are connected to the daemon and
it will also show your sync progress (the wallet also needs to sync your
balances, but it only takes a few minutes to an hour depending on hardware).

This might be helpful for you:
https://github.com/monero-ecosystem/monero-GUI-guide/blob/master/monero-GUI-guide.md.

> 
> Or... does monero-wallet-cli commands take it from here? As you can my tell 
> my fogginess is with the addition of the GUI.
> 

You can use either the gui or the cli with the same wallet. It's really
just a matter of preference.

> 
> I've also taken a look at './monerod --help>

That will give you the daemon's options. If you want the cli options you
need to run `monero-wallet-cli` from the wallet vm and the type `help`
at the prompt.

>> The infomation online is a bit scattered however I completely
understand if you'd rather point me some links or resource instead. Any
more guidance is appreciated.
> 

Try here for further reading:
https://ww.getmonero.org/resources/user-guides/.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/fd921760-aa0f-f15d-18c0-74c4552e6070%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] alternative to bloated templates for faster work and minimal boot time/resources used

2018-12-12 Thread qubenix


> But here's how you could start the loop:
> 
> qvm-ls --running -O name | (read line; while read line; do qvm-run -p
> $line 'your vm command goes here'; done)
> 
> There is an extra 'read line' at the start to get rid of the qvm-ls header.

Adding `--raw-data` should avoid the header (untested).


-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/305c855b-7498-a61f-72aa-abef0c10%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-11 Thread qubenix
OGBaby:
> Thanks Qubenix,
> 
> Wouldn't a fully synced daemon mean the blockchain is downloaded onto disk? I 
> was under the impression a benefit to remote node over local was to entirely 
> avoid downloading the blockchain. 
> 
> With the bootstrap-daemon address attempting to alleviate users from becoming 
> discouraged or impatient during the long-wait by temporarily letting them use 
> remote nodes while it syncs local. Am I misinterpretating Monero's remote 
> node all together?
> 
> I can definitely increase the vm but there isn't 75G available. Please let me 
> know your thoughts. 
> 

Using a remote node is a completely different scenario than what this
guide is doing. This guide is the safest way to use Monero that requires
no trust in third parties, using a remote node is near to the least
safest way and relies on third parties to give you information about the
state of the blockchain and thus your funds.

If you want to use a remote node I would suggest making a new vm, with
networking, and use that as your remote node wallet. You lose a ton of
security that way, as now your wallet is connected to the internet.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/c1a4af42-5a0d-7b16-ba6e-c0d958b78035%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-10 Thread qubenix
OGBaby:
> On Monday, December 10, 2018 at 5:16:01 PM UTC-6, qubenix wrote:
>> The best thing for you to do is:
>>
>> 1. Start the daemon's AppVM fresh.
>> 2. In a terminal on the daemon's vm do: `sudo tail -f
>> /home/monerod/.bitmonero/bitmonero.log`.
>> 3. See what is happening in the log and report back. You can paste the
>> log to a site like paste.debian.net or similar if you have trouble
>> making sense of it.
>>  a. **Only if the log is sitting completely dormant** do: `sudo
>> systemctl status monerod` and then: `sudo journalctl -xe`.
>>  b. Report back the result of those two.
>>
> 
> No problem.
> 
> The Monerod logs: paste.debian.net/hidden/5a996a7a
> 
> [Btw, I was interrupted during my session. I've marked #2 to mark the new 
> logs upon restarting vm's fresh]
> 
> Also, could you clarify if this setup will leave the GUI as a view-only? 
> Considering it's offline.
> 

>From the logs: 'Free space is below 1 GB on /hom'.

Tells me your out of space on the daemon vm. Increase your private
storage size to at least 75G. You can do it from the qube manager gui,
or from a dom0 terminal with: `qvm-volume resize monerod-ws:private 75G`.

The monero gui will work 100% once your daemon is synchronized, from the
logs you are at 4% complete. You cannot use a remote node with it
because the wallet vm has no connection to the outside world, set it to
use a local node.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/eea4630f-bf17-76d4-358f-a1a512f5b828%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-10 Thread qubenix
OGBaby:
> Greatly appreciate your help Qubenix. 
> 
> I can confirm my systemd file (/lib/systemd/system/monerod-mainnet.service) 
> matches yours now. I have removed the following to do so:
> 
> ConditonPathExists=/var/run/qubes-service/monerod-mainnet
> After=qubes-sysinit.service

That was not needed. Those will have no effect on your connectivity.
They just give you the ability to turn the service on/off from dom0 via
`qvm-service`. I don't remember why I omitted them from the Github post.

> 
> It is now identical to yours. Thank you.
> 
> Unsure if 'sudo systemctl restart monerod-mainnet.service' is sufficient so 
> I've stopped the daemon and rebooted instead.
> 
> I did figure the Node settings wouldn't work via the GUI. I've tried 
> '--daemon-address' as well as '--daemon-host' but it didn't work via 
> monero-wallet-ws terminal. I've just attempted to pass these commands wihin 
> the Daemon:
> 
> sudo -u monerod monerod --daemon-address node.moneroworld:18089
> 
> I'm sure that isn't a valid input for option. How would you connect to remote 
> nodes within the Daemon vm?
> 
> I've only found the '--bootstrap-daemon-address' command listed here: 
> https://monerodocs.org/interacting/monerod-reference/
> 

The best thing for you to do is:

1. Start the daemon's AppVM fresh.
2. In a terminal on the daemon's vm do: `sudo tail -f
/home/monerod/.bitmonero/bitmonero.log`.
3. See what is happening in the log and report back. You can paste the
log to a site like paste.debian.net or similar if you have trouble
making sense of it.
 a. **Only if the log is sitting completely dormant** do: `sudo
systemctl status monerod` and then: `sudo journalctl -xe`.
 b. Report back the result of those two.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/7f9fa29a-4b18-e4f0-ab8d-788c01c39311%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-10 Thread qubenix
ogbab...@gmail.com:
> I have set two AppVMs and one TemplateVM for (split?) isolation of Monero. 
> The Daemon has networking enabled and the GUI (monero-wallet-ws) does not. 
> Qrexec seem to make this setup possible. I, however, am having trouble 
> connecting to node.moneroworld.com:18089, let alone 
> zdhkwneu7lfaum2p.onion:18099
I also use this setup without any problems. I did have to modify the
`systemd` unit after the recent Monero update[1].

Try to adjust your file on the template to match what I have in the
link, restart the daemon, and see if that helps your connectivity
issues. The major changes are adding `/usr/bin/torsocks` to the
`ExecStart` and changing the `Type` to `simple`.

As far as connecting to remote nodes, are you doing that in the daemon
or the wallet vm? The wallet vm has no networking and so will never be
able to make a connection to anything besides the daemon vm.

[1]:
https://github.com/monero-project/monero/issues/4468#issuecomment-429671939

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/3dbad9f3-5fbc-f295-65c0-72c6aa85cbdd%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Donation costs

2018-11-24 Thread qubenix
Achim Patzner:
> Patrick Schleizer wrote on Mon, 19 November 2018 08:33
>> I don't think crypto currencies add much carbon dioxide
>> compared to
>> legacy financial institutions.
> 
> Answers like this make me wonder how people arrive at their
> threat assessments.
> 
> If you do not know the facts making assumptions based on
> your wishes does not work. I strongly believe in finding
> facts if I do not have precise data. Try taking a look at
> some research:
> https://www.nature.com/articles/s41893-018-0152-7.epdf (if
> you do not want to pay for the article you will be able to
> read it at sci-hub). The current equivalent of the creation
> USD 1 in Bitcoin (at the time of writing the article when
> Bitcoin was still more expensive than today) is about
> 17MJoule (about 4.6kWh). Gold is currently at 5MJ. The
> mining of the first 6 months of this year took 30TWh,
> estimate for the year is 73TWh. If we're lucky this will
> have led to less than 70Mt carbon dioxide. If not we will
> have gained quite some nuclear waste we still don't know how
> to deal with.
> 
> And as you are making noises about banks: Please add in the
> environmental cost of all the computers involved in Bitcoin
> transactions. One Bitcoin transaction is currently costing
> about as much energy as 40 credit card transactions.
> 
> And yes, the reference section of the article is quite
> interesting.
>  
> 
> Achim Patzner
> 

Good response to this flawed, ignorant study:
https://twitter.com/nic__carter/status/1056976815032582144.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/1dcfe60d-8c74-3f98-8e66-c5097d5e2dbe%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] how do I check Tor & Whonix version?

2018-11-03 Thread qubenix
qubes123...@gmail.com:
> Thanks a lot for your tips and advice, my Tor version in Qubes4.0 - Whonix is 
> ​​0.3.2.9. Which Tor version is currently the most current and the safest? I 
> do not know the goal is 1000% safe but which is the best and safest version 
> currently? However, I could not figure out my Whonix version, how can I find 
> out which Whonix version I have? And if my Tor version is not backed up at 
> the moment, how can I upgrade this? Thank you for everything in advance. ;)
> 

Sounds like you're on Whonix 13. That would explain why you aren't able
to easily find your version number. Another giveaway is your Tor
version. On Whonix 14 I have Tor version 0.3.4.8.

If you want to upgrade to Whonix 14 see here:
https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/7b5c295e-19dc-db69-ca95-26a1e0381082%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] how do I check Tor & Whonix version?

2018-11-01 Thread qubenix
qubes123...@gmail.com:
> I entered -> "whonixcheck --verbose --function show_versions" and got this, 
> see screenshot in the link.
> 
> https://ibb.co/b2GZq0
> 

In your pic you forgot the underscore in `show_versions`, no need for
sudo. This will not give you your Tor version. For that you have to run
`tor --version` from the gateway.

You could also just do `cat /etc/whonix_version` from the workstation or
gateway for your Whonix version. I mention it because whonixcheck
produces output you don't need.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/26cec056-151c-b939-c306-04fe563ed461%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Two VPN questions and one Qube Manager question.

2018-11-01 Thread qubenix
birdynam:
> To get your vpn randomly, just replace the openvpn.ovpn file in rc.local
> by something like `ls *.ovpn|shuf -n 1` might do the job.
> 
> AppVM → sys-vpn → sys-firewall → sys-net should be ok. Just put rules in
> your sys-vpn (/rw/config/qubes-firewall-user-script)
> 
> Birdy.
> 
> 

I've been using `remote-random` in my config for this. From the openvpn
man page it is explained:

--remote-random
When  multiple --remote address/ports are specified, or if con‐nection
profiles are being used, initially randomize the order of the list as a
kind of basic load-balancing measure.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/fb05aaed-6546-898b-a881-91e3b4f3a3d6%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] My farewell to Qubes OS!

2018-10-25 Thread qubenix
Joanna Rutkowska:
> Hello Qubes devs and users!
> 
> It's been nearly 9 years[*] since I sent the first internal email
> within ITL to Rafał Wojtczuk and Alex Tereshkin with the original idea
> for making Qubes OS. Shortly after this, we started drafting the
> original architecture and writing some early PoC code...
> 
> Today, I've made an announcement I'm switching focus to another area
> of work and joining the Golem Project as a Chief {Strategy, Security}
> Officer:
> 
> https://www.qubes-os.org/news/2018/10/25/the-next-chapter/
> 
> https://blog.golemproject.net/joanna-rutkowska-joins-golem-as-chief-strategy-security-officer-13f12f0c11c0
> 
> I'd like to thank all the people who made Qubes OS possible, which
> includes: the whole ITL team, all the community contributors, and, of
> course, all the Qubes OS users!
> 
> Qubes OS will continue under the lead of Marek Marczykowski-Górecki,
> who have been a de-facto lead for all the day-to-day development for
> quite some time already!
> 
> Thanks, Marek! Thank you, all!
> 
> Cheers,
> joanna.
> 
> [*] FWIW, the exact date was November 11th, 2009.
> 
Thank you for all your contributions. Your standards for security and
best practices have been an inspiration to me.

I wish you the best of luck and success in the future.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/fe9cb528-6a3c-06b7-6e21-370cbe9ac60b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Autostart fedora keychain service in a qube?

2018-10-23 Thread qubenix
'Bjoern Christoph' via qubes-users:
> I've set up a Nextcloud server in my LAN. This one works fine on all my 
> systems, works very well in Qubes 4.0 using a Fedora 26 qube and also 
> autostarts.
> 
> I specifically use Nextcloud to sync my keepass file across all systems, 
> that's pretty important as this file changes often.
> 
> The problem using autostart for nextcloud though is that when the qube starts 
> I am asked to enter the password for my nextcloud user account.
> 
> The popup states:
> 
> "Reading from keychain failed with error: 'No keychain service available'"
> 
> Now I could of course start keepass, copy my cryptic password into the popup, 
> then once nextcloud is running close keepass so that the keepass file is 
> updated if required and then start keepass again.
> 
> Um... no not really, that's very annoying.
> 
> I checked the group and have not found anything helpful here. I don't think 
> that this is a too uncommon problem? Any suggestions on how to solve it?
> 
> Thanks a lot!
> 
> Best regards,
> Bjoern
> 

Off the top of my head: set keepass to automatically save all changes.
Then your file is always up to date.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/a95510f7-c964-39c6-95ae-692dfc4802c3%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] firefox plugins on disp templates?

2018-10-19 Thread qubenix
Stumpy:
> I realize this is marginally relevant but thought that I am likely not
> the only/first one to think about this so Id reach out to see if anyone
> else has solved it.
> 
> I LOVE the disp feature and use it fairly often for random browsing,
> but, I miss a few addons. I managed to add them to my template (which I
> am think might be bad op/sec juju) but even then, when a new addon comes
> out the browser updates so I have to update the addon manually in the
> template which is a PITA that is quickly becoming not worth it.
> 
> So, is there a way to have addons in a browser in a dispappvm and avoid
> this issue?
> 
This should help you: https://www.qubes-os.org/doc/dispvm-customization/.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/f1220884-d7fb-afcc-1cb2-e2af935860af%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix

2018-10-15 Thread qubenix
> Exactly the same issue.
> Running monerod with torsocks was working for me too.
> 

Check my comment here:
https://github.com/monero-project/monero/issues/4468#issuecomment-429671939

Running monerod like that from systemd or the command line (with or
without --non-interactive doesn't matter, only with systemd needs it) is
the best experience I've had with it on Whonix in years.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/d28d837a-6120-c54a-52cf-91b363f24fe8%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix

2018-10-14 Thread qubenix
qubenix:
> mk:
>> One last thing,
>>
>> It should be noted that I still had to remove option 
>> "--p2p-bind-ip=127.0.0.1" to let monerod bind on 0.0.0.0 to make it work.
>>
>> Any security implication about this ? Does all traffic is still routed 
>> through Tor network ?

Forgot to mention that there is no security problem to bind on 0.0.0.0.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/0dbc186f-4c46-fe6b-e8d7-3e66af1cddcc%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix

2018-10-14 Thread qubenix
mk:
> One last thing,
> 
> It should be noted that I still had to remove option 
> "--p2p-bind-ip=127.0.0.1" to let monerod bind on 0.0.0.0 to make it work.
> 
> Any security implication about this ? Does all traffic is still routed 
> through Tor network ?
> 

If you are using gateway sys-whonix then all of your traffic is always
using Tor.

Not sure what you mean about "make it work", but I'm having some
stalling/connection issues[1][2] on the newly released version (v0.13.0).

At first connection issues were solved by adding torsocks to monerod
when using Whonix gateway or binding p2p ip to 0.0.0.0 if not using a
Whonix gateway. Next I started to experience stalls, which I still
haven't found a solution for yet.

[1] https://github.com/monero-project/monero/issues/4468
[2] https://github.com/monero-project/monero/issues/4469

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/c3466858-cc53-118b-3e79-11ef6de7c132%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix

2018-10-14 Thread qubenix
mk:
> qubenix,
> 
> I thought I had to run a full node to be synced with main blockchain but I 
> now understand that running a local node is enough
> 
> So everything works as expected,
> 
> Thanks for you answer and clarification :)
> 

It's still a full node because you fully validate all transactions and
blocks as they come in. You just don't send them to new nodes trying to
sync.

Glad it helped.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/ffc22c09-06c7-494e-baea-7d09af6a3113%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix

2018-10-14 Thread qubenix
mk:
> Hi guys,
> 
> Thanks for your work on this.
> 
> Setup is working fine for me except that I could not find a way to properly 
> forward i2p port (18080) from outside to monerod-ws when using sys-whonix as 
> the netVM, I had to switch to sys-firewall.
>> (Script used to setup port forward
https://gist.github.com/Joeviocoe/6c4dc0c283f6d6c5b1a3f5af8793292b)
> 
> any ideas on how to fix this ?
> 

It's not i2p port, it's the p2p (peer to peer) port.

1. You don't need to open that port unless you want to. It's only used
for serving blocks and transactions to other nodes. Monero's
documentation suggests to not open that port when using Tor.

Not to be confused with the rpc port (18081), which is opened when
wanting to create a remote node for light clients to connect to.

2. If you want to keep using sys-whonix as NetVM (better for privacy),
and you still want to open the port, use a Tor hidden service:
https://whonix.org/wiki/Hidden_Services.

You'll just have to advertise your onion address out of band somehow
because Monero doesn't have a setting like externalip= to let peers know
about your onion. Probably not worth it.

3. If you want to use sys-firewall you'll have to remove the
p2p-bind-ip=127.0.0.1 from the /lib/systemd/system/monerod.service file
on the TemplateVM. You will probably also have to allow the port forward
on your home router somehow.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/5e2c15c7-e5b1-5ae0-187e-22cc2adca019%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Problems with split PGP (QUBES_GPG_DOMAIN) in 4.0 + fedora 28

2018-10-07 Thread qubenix
Zbigniew Łukasiak:
> 1. QUBES_GPG_DOMAIN env variable somehow gets cleared between the
> shell and the Enigmail process. I set it in the shell before starting
> thunderbird:
> 
> user@personal:~$ export QUBES_GPG_DOMAIN=work-gpg
> user@personal:~$ echo $QUBES_GPG_DOMAIN
> work-gpg
> user@personal:~$ thunderbird &
> 
> But when I look at the Enigmail debug console I get this error:
> 
> enigmail> /usr/bin/qubes-gpg-client-wrapper --charset utf-8
> --display-charset utf-8 --no-auto-check-trustdb --batch --no-tty
> --no-verbose --status-fd 2 --fixed-list-mode --with-colons
> --list-config
> ERROR: Destination domain not defined! Set it with QUBES_GPG_DOMAIN
> env variable.
> 
> 
> 2. Enigmail somehow refuses to accept
> /usr/bin/qubes-gpg-client-wrapper as correct setting even if it
> apparently uses it (see above).  I keep getting this erro message:
> 
> Enigmail: Error in accessing Enigmail service In order to use
> Enigmail, GnuPG is required. If you did not install GnuPG yet, the
> easiest way to do this is using the "Setup Wizard" button below.
> 
> And then when I set it up in the wizard I keep getting:
> 
> "The file you specified is not a GnuPG executable. Please specify a
> different file."
> 
> Thunderbird data:
> Name Thunderbird
> Version 60.0
> Build ID 20180829122858
> Update History
> User Agent Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
> Thunderbird/60.0
> OS Linux 4.14.67-1.pvops.qubes.x86_64
> 
> 
> 

Not sure why Enigmail is not recognizing the env var, but you could put
your gpg domain into the file /rw/config/gpg-split-domain as a
workaround. I use this method without any issues on r4.0.

Not sure about your second issue as I've personally never that problem.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/e69bc191-6a91-6d35-e52e-a2e6580735a6%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Signal installation returns gpg: no valid OpenPGP data found.

2018-09-25 Thread qubenix
qubes-...@tutanota.com:
> I try to install the Signal to my debian-9 template, following the guide 
> https://www.qubes-os.org/doc/signal/ <https://www.qubes-os.org/doc/signal/> .
> 
> After I initiate 
> $ curl -s https://updates.signal.org/desktop/apt/keys.asc 
> <https://updates.signal.org/desktop/apt/keys.asc> | sudo apt-key add -
> I get 
> $ gpg: no valid OpenPGP data found.
> 
> Thank you
> 

You have added this part
"<https://updates.signal.org/desktop/apt/keys.asc>" accidentally. The
correct command, as shown in the guide, is:

curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add -

This should work as expected, I just tested it.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/ee063803-5308-39bc-d192-150f3cab93b8%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: whonix-ws-14 apt-get autoremove broke the template

2018-09-18 Thread qubenix
sbore...@gmail.com:
> Am Montag, 17. September 2018 23:48:27 UTC+2 schrieb qube...@tutanota.com:
>> hi, after the last update of the whonix-ws-14 template with recommended 
>> apt-get autoremove, the template got broken. 
>> - Most of the apps disappeared
>> - torbrowser doesnt connect to net
>> - template itself cant be updated. 
>>
>> user@host:~$ sudo apt-get update
>> Reading package lists... Done
>> E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource 
>> temporarily unavailable)
>> E: Unable to lock directory /var/lib/apt/lists/
>>
>> Upon launching TorBrowser, the wellcome page is "File not found". Upon 
>> trying to connect to a web page, "Secure connection failed".
>>
>> any ideas?
> 
> Hi,
> 
> was bitten by this as well. The whonix repos must have been in a strange 
> state yesterday (Sep 17), and a dist-upgrade removed too much stuff (with 
> essentially
> the symptoms you describe).
> 
> I bit the bullet and just reinstalled the whonix templates, followed by
> apt update/dist-upgrade/autoremove and today everything behaved as expected.
> 
> It would be great though if it were possible to avoid these 'flaky' states of
> the whonix repos ..
> 
> Best,
> 
> Stefan
> 

Happened to me from the `testers` repo yesterday too. Luckily I noticed
all the packages to be removed, declined the upgrade, and switched to
`stretch-proposed-updates` repo.

Don't forget you can always use `qvm-volume` to revert your template
changes (as long as you haven't restarted the vm since breaking it)
instead of reinstalling. See `qvm-volume --help` for details.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: 3AAF6650 F818BDBE 267C7866 E4A0C614 DBD5EEAD


-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: 3AAF6650 F818BDBE 267C7866 E4A0C614 DBD5EEAD

-- 
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/d1a16eec-7308-5298-fc45-286078540a91%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] how can i patch xen?

2018-09-15 Thread qubenix
Hello all.

I'm attempting to build a custom Qubes with one patch added to Xen. Is
it enough to simply add the patch with the others in
qubes-builder/qubes-src/vmm-xen/, add a line for it in
qubes-builder/qubes-src/vmm-xen/xen.spec.in, and then build?

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: 3AAF6650 F818BDBE 267C7866 E4A0C614 DBD5EEAD

-- 
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/e64bfe4b-5072-bc5d-c5c8-77bb486d007a%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL - MSI MS-7980 (update)

2018-09-10 Thread qubenix
This is an update to my current HCL entry:
https://qubes-os.org/hcl/#msi_ms-7980_i7-6700k_skylake_hd-graphics-530.

Since then I've added a GPU, updated BIOS, and moved to Qubes 4.0. Both
integrated graphics and the GPU can provide graphics without a problem.

Support file is encrypted to the following keys:

Andrew - BBAF910D1BC9DDF41043629FBC211FCEE9C54C53
Joanna - 49A322D9CA0D1D7DAEFA2AC63393D8BF0DDC6718
Marek - 86BA6E93318FBA446642A90ADB8FD31CCAD7D72C

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54

-- 
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/679a4c3a-134a-1496-f4ab-428e4bf9568b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
-BEGIN PGP MESSAGE-

hQIMA607L7LGhs0oAQ//WtQcRqKYvCCoxFs4TBZ2hlXWRsVjupo7ipbQbKQv5mU8
N07KMAjD8xd+NbmFKVS5YitBWQBqZwre3T5dUum3hiRPbVz9rZ86GnKbElSL88AD
sOsnsamvqppVloSrCgSYy0+XoT+XjSF2OsO+EBagGMDYndMPUM2yPLtPUNGxAAED
bHb8DsglbTDYDUJ5qmtshY9rHMPGhH6SZbA9TKbtRTid++epVOddOInE7sKmEP7Y
QDN6vXf4G4oEfkOuyXQGY9gpn2e9A4IkOdXeEQPQakNRgJsmeyq1ku33Zp9G/J4k
UrmqNOWFU8z/deVzU/BCxMHItwuftwWMaaRl4RJks76nSF6i/iIzoBbMmK3atZrJ
1BqQt64IGo/Z7CF2n23UeQIHA6iP8kobSwWy9MzbkcQ8XrYp213AolLkbldG19ZG
Fg/W5TwzsBdzJTw881URsZ95naV3fqL73B+sI7gijbSpQaZwvrUVUpobL9fByOYy
e/9OyP8jFUY6Pq13ckTUYZPYBF0zsFCXnHU70F7zPlfQbLm6ioD2spLwdfV+E+uZ
CEiATHShX2+KF4lGlHvC7BNMmKHYQPAummsPaRRAQyS3jGucT2efyETcxk6pkgQU
IuUiGm1EecImnAws4CoXnfcNhdX6tLf/DS6I+PKT6eS07tbIHEHTcKpskVbopx+F
AQwDqH2PP4A1NFQBB/9EdgfNZFGUkOGtehPCMOFyuI0J3DHsgyMQGsGP4N9J+PiU
gf/GERIvdzACcdC1/6OBKtqc7JxltrrgmuXcrE1MF4i/5A8q98uPkYdMpG7WJFGP
dxfmiv3J+/qZy0Dsr3/gE48TfSKdVSWI2mZFPdeZmp0qlMl1HSAHWtk80fiBrBPx
mPdjZY6F/5FZVZ9OtXRuuQ7KRNPqjggW8uMRNtmlJ1PQloQTayyNigm3CSlAoR+Y
W2MaCziIN+2lvK2QfzvoJ/X8tLwdJg9PxMZBZN+umYE9PJkFeDP3z1yIiPtYaKb8
DukuGS+f++nNZftWpFFOIeeUos5yNVWPC3vUMmaNhQIMA1oPwWKpItGOAQ/+LMFi
8CfMKaiisJv/tZeYwVMl9PrjWeuRHUzu4F2sernxI9u/rAgKP+l9/kMyV11N54mx
XseI0t8TIRf1cGBdMcm0zfvdKTUxrka3yrE/solbHWnlX9npytAFKv3mO6wE/4my
1VEiPY/4UqYvMivU3aS27OU9D4ZrP1Xb0Fc2z8rFfwD9t1as4mK9GW4TFAGopwsF
ALIaMfutquEvtd46iqoTPLSzLP9Swn1ZNABQ7Qp3KgKxpHvF0B9O1JcJQlOeIEKg
LGp5tuJcxieGwkUvaZg/Y2MxlAcJusWzKb1MKMptyH4jTG5ELrWWhJjXwEY9dAH7
uMYnyujhoPsXFFmz0r9NrlfOVkr+8R1Rev7OxS84HOM0kq3Wh5TpNxdrJ5tX8QFG
Bt2eLqKlZotyO83rgWpzw4UQxyb3uZcZYIOVZ274lQnn4Yzt+lyUJioiFZPL2a4b
JCXW9dHFZTvQ+/TwThV4UPJP4FpC8gz0wOinzxzsHkRxqR7DKHEFIU9XOQMiH1f/
NybAOIekx4VkmjHB3C508eYzNpDwYgwsR3lj8O1Jh+my//xjM2W1RxpHT2KGitrJ
Y/eAw+W13dCkFLXXixZWMu6q+fOi3sSA+HFsoD4mwLoqWPThcu8ryKCuyKJ09bLS
Rb0vjYHVX1t10TTOgF3cVS/nSFepRxUMD+GYphiFAgwDyh7gS80KxbUBD/94T1No
+gFNp+gQX2pKMVfWgZrzAso2c7SUnBy9WvGLt49meERVhfD5XOkoBebJ3F1N2xut
DklmlVYsXSefO2vLy3UlN6rUyU4KYUJitl5no23h92LJ8TxxHamxekANXiW8zHL0
rSjLtZdTiqKEHIExwYuxQx3cgn9tnq/Y+UjAGZu+oFzBWhZWM77sC/v4HFcjjSiu
UVW1662cSzBfGb1gpa32wJOJ3WjHqMQ5NE03zD0tXSW2Q0diZoLJkQbqEjBcfBxR
2FFK1UEhOyXTbaPB2WDYg5yEPadH36xuXJ7toADQhrZXt9QAHT5fLaR8U68ePE2Z
/8JXSfoyvFh1rAfvd8+0RfkW7W1rjCpLYWAbouOvT6qSZo7IKGbz1bcNsus+i6tb
2LLlJUDUQsbqLHZPD3AExKcTkb0KQ/pHwbiMtRi3CNNG3TNdw/oRYVvbCApUwmwy
2o8qI04+35sbsuKkIdyU4CHW/rjM2kjh0JABVCfpu6YK16WUWv8p4LoFxh4vhRvO
FXYoHc/3FW7uYNVf3ZBtoKLucC8mVsYp3QfMY0ZWHuc8jc+xz/fC99EmOrHLyqOW
s3rL+C3l/RpuzsiqW5jdUFe2ZrW8zrrZdA52MptqJ0MwIQmlUBpaUYxdboU3LWlP
tf9lE7nw5v8YaDEE9R2rgHBwgP8dJlZhi2S/q9LtAV5IY/j5Pf1U/YlJVhu15IJn
0lf5KZpdkNYm+ItMwfZoVq/60430beORWR6OIwNT+Wj6R3ciQJkmcW4bG2cjr2py
YSvCVUJInt6WzFJ5zDn6m1iZlDqx3WCOMWbYumO1oAenwsyRQDWNjZVMhyhgukXi
BxCrJyq0FgdM4QV32ZZ1cfvqc/CFWt8weLORZwalrJtwsogJmJGAHvpRzhTYB3cs
pSTqwtM66N7z21QAEu8YKJsjITXZDg9QL1oFruWJOkCeZGcj0S9pGy2EOmKcKHDa
EgwJy4by7hNkHt+6N5j/gmsbmrVmPub0NT8wmdkqnvo6DvmnjXUa/SH3uWiCRnmG
Znx7dtIdkiGNva+nvL2uq06yzHv+BpQ6n/rkbQG3zWhcqbirKmxYbtICuRBZS9KC
ng9ZBjJGWQWmKje9538IGFh297n7pk6S/SVIjxMSNVsfJTN0jTWTSbDrAiKD6UDA
8cPjojEJE8O2h86GTko3VU9I9nAUKN0Ly3XSjjZdVFBz3tHIETg3Sqm3lOJCWfbW
Wo62m4el/s8o9xoFJR8H2g7Hdlp7jSopCQQVXxZuWFDss9JXjQPQ5Y6EcxE2ncnM
cWEPlwj/Quwc0y5ztp+l1OPmYIPsuL1OG9613RUzPoPTMZG4FmONrIU+o7Dd1w0q
NQa1vpK0hMzLCZJCRsuXfLKRflT5sFEhHJL4x8foLsxwNPC7Gy81VwfH99EbVzRP
cc/zlXiXL5YOphvgFWSfXCWrJne0tPJsEH2zugFE8GehcTSOJmKLRfa424INfO69
enkeZUFIeJpOJQFvUHv0k9gZwqlHAsEPxbiwfl9J7l4OpQPqJiQNLT/p1kOqRkS/
+AFDDXzdGeyUFj5XO7o0Qq2YO1kp5w0/In8b7eEcF5SXjRfBeUz0MJIEZRNEP6LQ
P+W5Ps3Mz+igjGoPMS8vDgRDAg0g7ewY+voF+6UYX03WZTUHhBgQXmkQZdQxOBfz
jGioKi+5v1arE2LDGkKiBTdUMyYwYBo1nWpSxUN7z5bCt6aRBtSnev2KHL/NK3J3
bAr8TkMUShQwBEZWhfww63ApKoqd8A+rpXTxICnvx9PynK9hHtET1UxUrwVMEOpE
abpeij6kBGjzkv4FhLBxGW99fyZMz7UcPm9qAQF4ETVmYxfLOU2aP/qi5EBACws2
3qnKKDFvyzQ0mOyx9cJ4HOF6i4Qa4eSUq9C6F06fbQS9IPQKzfFFsYY097QO+ls3
HzeFphBz7DI0gqYx6DK//S4MoZZ5e8kgc9VXLc5nK8GU+P0butp1SjhvaAYVI5bR
HI17R7tgFaDpzxmhMgLpB4IO9BPDMXKEUsvAKp3oWbO9di9uqQL/e0fmvB7m6S/G
GJv/vwiPlDIEJdBhKs7gCnK1dsfN7vm

Re: [qubes-users] Re: why Whonix and not Tails or the anon-vm?

2018-05-17 Thread qubenix
john:
> On 05/17/18 06:25, awokd wrote:
>> On Thu, May 17, 2018 3:46 pm,
>> josefh.maier-revL73yDgGBWk0Htik3J/w...@public.gmane.org wrote:
>>> Hello Forum
>>>
>>> why was Whonix and not Tails selected for thes anon-vm of QubesOS?
>>> Thank's for your feedback!
>>
>> Don't know the exact discussion that led up to it, but I imagine it's due
>> to the flexibility Whonix-Gateway provides by permitting anything
>> attached
>> to it to get routed through Tor. It is still possible to run Tails under
>> Qubes, see https://www.qubes-os.org/doc/tails/.
>>
>>
> technically this is a whonix question, I would suggest  posting there :
> 
> https://forums.whonix.org/
> 
> or read their docs a bit 1st, then  patrick and crew  respond to most
> posts .
> 
I believe it started here:
https://blog.invisiblethings.org/2015/06/04/otf-funding-announcement.html.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/b48a06b0-49b0-e468-6c64-62e8564d6d9c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] opening links in another VM opens two browsers

2018-05-12 Thread qubenix
awokd:
> On Fri, May 11, 2018 2:56 am, qubenix wrote:
>> Hey everyone! Hope you are all doing well.
>>
>> I followed the guide here: https://www.qubes-os.org/doc/tips-and-tricks/
>> so links clicked in one debian-9 AppVM will open in separate debian-9
>> AppVM. What actually happens is interesting.
>>
>> If I have firefox running in the destination VM already, everything
>> works as expected. The link opens a new tab in the proper AppVM.
>> However, if firefox is not currently running, a clicked link will open
>> the link in a browser in both VMs.
> 
> Tried to recreate but couldn't. It might be a function of the application
> you are using. What happens if you click links in a different app?
> 
> 

You're right, in other applications everything works as expected. The
app in question is discord for the record, and I'm not surprised it's
doing unexpected/unwanted things. That's why I was just testing it out
in a dedicated VM. Thanks for the tip.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/4cb66b99-1e76-f06d-2efd-59c439900696%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] opening links in another VM opens two browsers

2018-05-10 Thread qubenix
Hey everyone! Hope you are all doing well.

I followed the guide here: https://www.qubes-os.org/doc/tips-and-tricks/
so links clicked in one debian-9 AppVM will open in separate debian-9
AppVM. What actually happens is interesting.

If I have firefox running in the destination VM already, everything
works as expected. The link opens a new tab in the proper AppVM.
However, if firefox is not currently running, a clicked link will open
the link in a browser in both VMs.

Any ideas?

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/47091bca-90fe-286a-e851-008d3f8af1c4%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Ledger Nano S

2018-05-02 Thread qubenix
bojanso...@gmail.com:
> In Qubes 4 I can connect all kinds of USB devices via the device selector in 
> the upper right corner of the window. The Ledger Nano S is a hardware wallet 
> for cryptocurrencies. Ledger Manager is an extension for Chrome/Chromium 
> webbrowser. When I connect Ledger Nano S to a USB-port it is recognized by 
> Qubes and I can select to which VM it shoud be assigned to but it is not 
> recognized by the Ledger Manager. The Ledger Nano is recognized by Ledger 
> Manager in other OP's like Windows 10 and different Linux. Any ideas about 
> what the cause could be?
> 
> I have tested sys-net, sys-firewall and sys-whonix. No difference.
> Also tested StandaloneVM based on Fedora26, Debian9 and Windows7. No 
> differences.
> 

It might have something to do with udev rules in your target VM. See
here:
https://support.ledgerwallet.com/hc/en-us/articles/115005165269-What-to-do-if-my-Ledger-Nano-S-is-not-recognized-on-Windows-and-or-Linux-

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/25e4c33c-f47c-e074-1633-863d151dffd1%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Guide: Monero wallet/daemon isolation w/qubes+whonix

2018-04-21 Thread qubenix
qubenix:
> pauHana:
>> After completing the to VM setups and shutting them down is the intention 
>> then to start monero-wallet-ws and interact with the wallet thru this vm as 
>> per the usual ./monero-wallet-cli?
>>
> 
> Correct. You should be able to run the gui from monero-wallet-ws as
> well, but I haven't tried it myself.
> 
> --
> qubenix
> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> 

Please don't delete the conversation so the next person that has this
trouble can see everything together.

Is your daemon sync'd fully?

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/043be5f4-fca2-9e47-4845-06d3b1dc3cf7%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Guide: Monero wallet/daemon isolation w/qubes+whonix

2018-04-21 Thread qubenix
pauHana:
> After completing the to VM setups and shutting them down is the intention 
> then to start monero-wallet-ws and interact with the wallet thru this vm as 
> per the usual ./monero-wallet-cli?
> 

Correct. You should be able to run the gui from monero-wallet-ws as
well, but I haven't tried it myself.

--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/ae14b912-564e-d523-9633-7f8bf5bf9627%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Best pratice for crypto-currency wallets?

2018-04-07 Thread qubenix
Dave C:
> On Monday, August 21, 2017 at 8:33:32 PM UTC-7, Francesco wrote:
>> Anguilla
>>
>>
>>
>>
>> On Mon, Aug 21, 2017 at 8:14 PM,  <anguil...@gmail.com> wrote:
>> I'd like to use Qubes for my crypto-currency wallets.
>>
> 
> I scratched my own itch and made a qubes-friendly tool for XRP transactions.  
> I'd like to build the same for BTC, etc... but I don't yet know those as well.
> 
> Details on https://www.dave-cohen.com/blog/rcl-tool/
> 
> -Dave
> 
>  
> 
You can put any wallet in an offline VM and use qrexec to forward the
needed ports from your daemon. Here's a guide for doing it with monero:
https://getmonero.org/resources/user-guides/cli_wallet_daemon_isolation_qubes_whonix.html.
The same basic procedure can be used for most crypto wallets.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/560af0d7-da9e-94b8-1f76-4030bd31d458%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: unexpected system restart

2018-04-02 Thread qubenix
cooloutac:
> On Monday, April 2, 2018 at 12:31:09 PM UTC-4, qubenix wrote:
>> Hello all. I'm currently still on R3.2.
>>
>> I had a situation where I was working with a normal (for me) amount of
>> VMs running. Nothing even close to extreme as far as cpu/mem/io/temp.
>> During startup of an AppVM that I use all the time, my system just did a
>> hard shutdown ("no input" on screen, connected with hdmi) and then right
>> into a restart.
>>
>> How can I debug this in a useful way? Does someone have an idea what
>> might cause it?
>>
>> -- 
>> qubenix
>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> 
> weird.  you using sleep mode at all?  Checked the obvious issues like temps,  
> hdd errors,  memory stability?
> 

No sleep, checked all obvious issues.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/e8db6aa6-f9d7-d833-cd63-ecd3cbd65c7b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] unexpected system restart

2018-04-02 Thread qubenix
Hello all. I'm currently still on R3.2.

I had a situation where I was working with a normal (for me) amount of
VMs running. Nothing even close to extreme as far as cpu/mem/io/temp.
During startup of an AppVM that I use all the time, my system just did a
hard shutdown ("no input" on screen, connected with hdmi) and then right
into a restart.

How can I debug this in a useful way? Does someone have an idea what
might cause it?

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/a55ee19d-0d67-2b53-667a-a0179dfe3acc%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread qubenix
> So let me be blunt as this is likely the last email from me to qubes
anyway;

Bye, I'm happy to see you go away finally. It was killing me inside that
you were working on the new gui controller. Fuck off back to bcash.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/2b004517-b9b8-6507-dd04-173728dc3999%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Intel igd: boot freezes on kernels 4.9.5+

2017-11-10 Thread qubenix
I'm using Qubes 3.2, I've got an i6700K cpu connected with hdmi. Only
kernel 4.9.45-21 will boot when using Intel igd. If I try to boot from
either 4.9.54-21 or 4.9.56-21 using igd the process just hangs at a
certain point. I've attempted the solution presented here:
https://qubes-os.org/doc/intel-igfx-troubleshooting/, along with
"iommu=force" and "iommu=on". None fix the problem, but adding
"iommu=no-igfx" causes a boot loop instead of a freeze.

Any suggestions? I've got a gpu that works on the newer kernels, but I'd
prefer to use the igd for dom0 and save the gpu for passthrough.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/a0192f90-7f67-99d4-d4e0-ad3a2da97d2d%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Audio in Debian VMs just disappeared?

2017-10-18 Thread qubenix
Foppe de Haan:
> On Wednesday, October 18, 2017 at 12:38:05 AM UTC+2, Stumpy wrote:
>> hm...
>>
>> Is there something else I can post that would make this easier to diag? 
>> I really really would like to resolve this.
>>
>> On 16.10.2017 02:28, Stumpy wrote:
>>> No one?
>>> I still haven't figured this one out
>>>
>>> in case the private/paste bin was causing no responses here is the
>>> output from VLC:
>>> from the vlc window:
>>> "Audio output failed:
>>> The audio device "default" could not be used:
>>> No such file or directory."
>>>
>>> and from the term that I started vlc from:
>>> VLC media player 2.2.6 Umbrella (revision 2.2.6-0-g1aae78981c)
>>> [5e890a526938] pulse audio output error: PulseAudio server
>>> connection failure: Connection refused
>>> [5e890a4410e8] core libvlc: Running vlc with the default
>>> interface. Use 'cvlc' to use vlc without interface.
>>> ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
>>> ALSA lib conf.c:4528:(_snd_config_evaluate) function
>>> snd_func_card_driver returned error: No such file or directory
>>> Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared
>>> object file: No such file or directory
>>> ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
>>> ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_concat
>>> returned error: No such file or directory
>>> ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
>>> ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer
>>> returned error: No such file or directory
>>> ALSA lib conf.c:5007:(snd_config_expand) Evaluate error: No such file
>>> or directory
>>> ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM default
>>> [5e890a526938] alsa audio output error: cannot open ALSA device
>>> "default": No such file or directory
>>> [5e890a526938] core audio output error: module not functional
>>> [76de94d7eaa8] core decoder error: failed to create audio output
>>> Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared
>>> object file: No such file or directory
>>> [76de74001268] xcb_xv vout display error: no available XVideo 
>>> adaptor
>>>
>>> anyone?
>>>
>>>
>>> On 07.10.2017 23:12, Stumpy wrote:
>>>> For some reason the audio in all my Debian VMs has stopped working?
>>>> AFAIK I haven't done anything other than regular updates. I didn't
>>>> notice until recently so I am not sure about exactly when it started.
>>>>
>>>> In the audio mixer window none of the debian vms are showing up. I
>>>> tried plaing something in VLC and it gave the follwoing errors:
>>>>
>>>> https://privatebin.net/?f36509f33694a053#821JIyu4z/YqpQ61qGRYFP9Bspo7DAP8HmkPJCAk9Q8=
>>>>
>>>> Also,  another strange, maybe unrelated thing happened, I don' thave
>>>> nautilus in my debian VMs any more and I tried to reinstall then but
>>>> error saying I had some missing dependencies?
> 
> pulseaudio-qubes is still installed?
> 

Must be something with version 11.1-1 of pulseaudio. I've got the same
problem on a Kali VM that has the following pulse packages:

$ sudo dpkg -l | grep pulse
ii  gstreamer1.0-pulseaudio:amd64
1.12.3-1 amd64GStreamer plugin for
PulseAudio
ii  libpulse-mainloop-glib0:amd64
11.1-1   amd64PulseAudio client
libraries (glib support)
ii  libpulse0:amd64
11.1-1   amd64PulseAudio client
libraries
ii  libpulse0:i386
11.1-1   i386 PulseAudio client
libraries
ii  libpulsedsp:amd64
11.1-1   amd64PulseAudio OSS
pre-load library
ii  pulseaudio
11.1-1   amd64PulseAudio sound server
ii  pulseaudio-utils
11.1-1   amd64Command line tools for
the PulseAudio sound server

However on another Debian stretch template audio is normal. The pulse
packages there are:

$ sudo dpkg -l | grep pulse
ii  gstreamer1.0-pulseaudio:amd64     1.10.4-1
   amd64GStreamer plugin for PulseAudio
ii  libpulse-mainloop-glib0:amd64 10.0-1+deb9u1
   amd64PulseAudio client libraries (glib support)
ii  libpulse0:amd64   10.0-1+deb9u1
   amd64PulseAudio client libraries
ii  libpulsedsp:amd64 10.0-1+deb9u1
   amd64Pu

Re: [qubes-users] Re: Keepass vault password no worky

2017-07-19 Thread qubenix
yreb-qusw:
> On 07/19/2017 05:53 AM, qubenix wrote:
>> qubester:
>>> On 07/18/2017 02:27 PM, '0brand' via qubes-users wrote:
>>>> I've been trying to resolve a problem with both of my Debian-8
>>>> vault-appvms.. For some reason my Keepass passwords no longer work.
>>>> When I type in the password I get this message:
>>>> Unable to open database. Wrong key or database file is corrupt
>>>> I have been using the same password for both my Keepass databases for
>>>> quite some time now so the problem isn't due to forgetting or
>>>> miss-typing my passwords. Normally this would not be much of a problem
>>>> except for the fact that restoring from backups is not remedying the
>>>> issue. I've restored both my Keepass vault-appvms and my Debian-8
>>>> Template.
>>>> Looking back at the day before this happened there is only one thing
>>>> that I did that may have contributed to the problem. I removed my
>>>> sys-usb (netvm) and created a sys-usb (appvm). After I created the new
>>>> sys-usb I realized that It would not run unless I set pci_strictreset
>>>> to false. This was not acceptable to me so I removed the new sys-usb
>>>> and created a new one with:
>>>> sudo qubesctl top.enable qvm.sys-usb
>>>> sudo qubesctl top.enable qvm.sys-usb
>>>> The reason I think this may have contributed to the problem is because
>>>> the first two times I tried to restore my appVMs things did not go
>>>> well. The first time the Gui completely froze and I was unable to
>>>> unmount the drive. The second time the backup-restore did not complete
>>>> but at least the screen did not freeze up. The third time I used a
>>>> backup from a couple days prior and everything went smoothly. It did
>>>> not solve the problem though. I still can not unlock my Keepass vaults.
>>>> I'm not really sure what to do next. Is it possible that my backups
>>>> are somehow being corrupted when I restore them? I'm a little
>>>> flustered at this point and I could use some guidance.
>>>> Thanks in advance
>>>>
>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>>>
>>>
>>> If it makes you feel better, I had the thing fail. with the same
>>> messages, and I'd swear, I did nothing at all, after that I stopped
>>> using it . as pretty pointless to use something that MUST be
>>> reliable and have it fail so easily, whatever caused it  IMHO  of course
>>>  ; I think mine was in the Vault VM
>>>
>>
>> Which Keepass? On debian:
>>
>> user@host:~$ apt-cache search keepass
>> keepass2 - Password manager
>> keepass2-doc - Password manager - Documentation
>> keepassx - Cross Platform Password Manager
>> kpcli - command line interface to KeePassX password manager databases
>> libfile-keepass-perl - interface to KeePass V1 and V2 database files
>>
>> I ask because I have been using keepassx for three or four years with
>> only two databases. I keep multiple copies on different storage devices
>> and I have had only one copy ever become corrupt, but it was the fault
>> of the usb device. I use keepassx and kpcli with pleasure.
>>
> 
> keepass2
> guess that is a good idea to keep copies in various places
> I don't actually know why I would use a usb device with keepass2, so
> that wasn't it.
> honestly, it was a trial, in the vault appVM  , I was a bit shocked that
> it failed within a few weeks, was enough, for me to use my other
> password manager instead ..YMMV of course
> 

To explain the usb stick, I keep a TAILS usb stick with me that has a
copy of my keepassx db on it. Just in case I need to access this data
while I'm away from any of my computers. It was this device that became
corrupted, but only after massive IO abuse. I knew it would be toast
sooner or later, but I always keep backups of this device as well.

Always follow 3-2-1 backup rule!
http://thehelpfulhacker.net/2011/08/04/the-backups-321-rule-illustrated/

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/80bbbfe1-9490-2b23-8f16-8b518b841516%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Bitcoin Node on appVM

2017-07-19 Thread qubenix
Unman:
> On Tue, Jul 18, 2017 at 09:08:20AM -0700, Max wrote:
>> On Tuesday, 18 July 2017 23:45:13 UTC+8, Unman  wrote:
>>> On Tue, Jul 18, 2017 at 08:33:37AM -0700, Max wrote:
>>>> Hi,
>>>>
>>>> I have installed the Bitcoin Core client and wish to allow inbound 
>>>> connections. Has anyone tried doing this? I am able to connect to the 
>>>> network with outbound connections but have had no success when trying to 
>>>> get inbound connections
>>>>
>>>> I have taken these steps:
>>>>
>>>> 1) Installed Bitcoin GUI in the template VM
>>>> 2) Run it in a dedicated AppVM, downloaded the entire blockchain and am in 
>>>> sync
>>>> 3) Configured port forwarding on the router, removed the firewall
>>>> 4) Followed the port forwarding steps 
>>>> (https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world)
>>>>  but replaced the port 443 in the instructions with 8333
>>>> 5) Tried to Telnet the IP address on the sys-net (appears to be 
>>>> 192.168.1.18 on the wlp0s1 and do check node on bitnodes.21.co but it is 
>>>> unable to connect to host / says my IP is unreachable
>>>>
>>>> Any advice
>>>>
>>>> Thanks,
>>>>
>>>> Max
>>>>
>>>
>>> I'm always worried when I see comments like "removed the firewall", or
>>> global changes to firewall rules. This is almost never the right thing
>>> to do.You should be able to put new permissive rules in the firewall
>>> and retain other protections.
>>>
>>> Anyway, 192.168.. is a private address, not routable on the internet.
>>> What you want to provide is the EXTERNAL IP address on your router.
>>> If you don't know this you can check it using nwtools.com, unless you're
>>> using Tor or a VPN, in which case just log in to the router and check.
>>>
>>> unman
>>
>> Hi Unman,
>>
>> Regarding the firewall changes - possibly I wasn't clear.
>>
>> The statement removing the firewall was simply me disabling it on the 
>> router. I wanted to eliminate this as a possibility before raising my 
>> questions here. The only changing of the firewall I have done in the Qubes 
>> OS is the iptables changes on the sys-net and sys-firewall VMs.
>>
>> As far as I understand, whilst I may have been a bit of a fool to put in my 
>> private address in the telnet, the Bitnodes website was testing the correct 
>> port on the external IP address I have. I am getting an unreachable message 
>> here. I only did the internal address from a different device on the same 
>> network.
>>
>> Thanks,
>>
>> Max
>>
> 
> Hi Max,
> 
> If you can monitor the router, you should be able to see the inbound
> traffic when you run that test.
> You can also run 'iptables -L -nv' on sys-net, and watch counters - again,
> you should see the counter increment when you run the test. (Watch a
> rule that allows traffic to port 8333, obviously)
> You can also watch counters on sys-firewall and the target qube.
> 
> By doing all this you should be able to see where the traffic is being
> blocked, without needing to use a network sniffer or dumping traffic.
> 
> Start at the outmost node, and work inwards. At the point where you dont
> see traffic you know the problem lies one hop upstream, (unless it
> doesn't get to the router obviously).
> 
> If you see the traffic inbound at the destination qube, then it's
> possible that you are blocking the return traffic on the way out. Just
> reverse the process to trace the outbound traffic.
> 
> unman
> 

Max,

Maybe you already know this, but you can use Tor to get through the
firewall. Actually, if you install Tor in your AppVMs template, Bitcoin
will set up the hidden service on the fly over the control port. If
you're using a Whonix gateway it's a little more work, but not hard and
I can help. Still helpful for the network. I use `onlynet=onion` in my
Bitcoin config, so definitely helpful for me!

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/0ac3255a-998d-fa03-60e8-5a5241d53a65%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Keepass vault password no worky

2017-07-19 Thread qubenix
qubester:
> On 07/18/2017 02:27 PM, '0brand' via qubes-users wrote:
>> I've been trying to resolve a problem with both of my Debian-8
>> vault-appvms.. For some reason my Keepass passwords no longer work.
>> When I type in the password I get this message:
>> Unable to open database. Wrong key or database file is corrupt
>> I have been using the same password for both my Keepass databases for
>> quite some time now so the problem isn't due to forgetting or
>> miss-typing my passwords. Normally this would not be much of a problem
>> except for the fact that restoring from backups is not remedying the
>> issue. I've restored both my Keepass vault-appvms and my Debian-8
>> Template.
>> Looking back at the day before this happened there is only one thing
>> that I did that may have contributed to the problem. I removed my
>> sys-usb (netvm) and created a sys-usb (appvm). After I created the new
>> sys-usb I realized that It would not run unless I set pci_strictreset
>> to false. This was not acceptable to me so I removed the new sys-usb
>> and created a new one with:
>> sudo qubesctl top.enable qvm.sys-usb
>> sudo qubesctl top.enable qvm.sys-usb
>> The reason I think this may have contributed to the problem is because
>> the first two times I tried to restore my appVMs things did not go
>> well. The first time the Gui completely froze and I was unable to
>> unmount the drive. The second time the backup-restore did not complete
>> but at least the screen did not freeze up. The third time I used a
>> backup from a couple days prior and everything went smoothly. It did
>> not solve the problem though. I still can not unlock my Keepass vaults.
>> I'm not really sure what to do next. Is it possible that my backups
>> are somehow being corrupted when I restore them? I'm a little
>> flustered at this point and I could use some guidance.
>> Thanks in advance
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
> 
> If it makes you feel better, I had the thing fail. with the same
> messages, and I'd swear, I did nothing at all, after that I stopped
> using it . as pretty pointless to use something that MUST be
> reliable and have it fail so easily, whatever caused it  IMHO  of course
>  ; I think mine was in the Vault VM
> 

Which Keepass? On debian:

user@host:~$ apt-cache search keepass
keepass2 - Password manager
keepass2-doc - Password manager - Documentation
keepassx - Cross Platform Password Manager
kpcli - command line interface to KeePassX password manager databases
libfile-keepass-perl - interface to KeePass V1 and V2 database files

I ask because I have been using keepassx for three or four years with
only two databases. I keep multiple copies on different storage devices
and I have had only one copy ever become corrupt, but it was the fault
of the usb device. I use keepassx and kpcli with pleasure.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/92461c9e-a320-196b-8f8b-d57670264ca0%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Copying between VMs from dom0

2017-06-28 Thread qubenix
wordswithn...@gmail.com:
> On Wednesday, June 28, 2017 at 10:07:04 AM UTC-4, qubenix wrote:
>> qubenix:
>>> wordswithn...@gmail.com:
>>>> I want to copy network connection profiles from sys-net to 
>>>> sys-net-profiles as my computer shuts down.
>>>>
>>>> I'm creating a bash script in dom0 to help with this.
>>>>
>>>> I could use 
>>>>
>>>> qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles 
>>>> /etc/NetworkManager/system-connections/*"
>>>>
>>>> ...but that will spawn a dom0 confirmation dialogue that I'd rather avoid 
>>>> (after all, dom0 is initiating the copy).
>>>>
>>>> I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I 
>>>> don't want to trust sys-net to initiate this copy on its own.
>>>>
>>>> Is there any way to directly copy files from one VM to another, executed 
>>>> directly from dom0?
>>>>
>>>
>>> Not sure if it's the best solution, but this should work for avoiding
>>> prompt (briefly tested):
>>>
>>> for i in $(qvm-run -a -p -u root sys-net "ls
>>> /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root "cat
>>> /etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm
>>> sys-net-profiles $i; done
>>>
>>
>> Oops small typo (forgot to name "sys-net" one time). Fixed:
>>
>> for i in $(qvm-run -a -p -u root sys-net "ls
>> /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root
>> sys-net "cat /etc/NetworkManager/system-connections/$i" > $i;
>> qvm-move-to-vm sys-net-profiles $i; done
>>
>> -- 
>> qubenix
>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> 
> How much of a risk do you think this is, passing the file contents through 
> dom0 via qvm-run -ap?
> 

Yeah, this is moderately secure IMHO. You are copying everything from
/etc/NetworkManager/system-connections dir to dom0 before being moved to
destination vm without check. So theoretically something malicious could
be placed there. However, I don't see how it would be executed in dom0
(should the file be malicious). I took no consideration for security,
only to solve the problem of prompt.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/5eef3931-4ff7-3f87-22f0-450353c8b47f%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Copying between VMs from dom0

2017-06-28 Thread qubenix
qubenix:
> wordswithn...@gmail.com:
>> I want to copy network connection profiles from sys-net to sys-net-profiles 
>> as my computer shuts down.
>>
>> I'm creating a bash script in dom0 to help with this.
>>
>> I could use 
>>
>> qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles 
>> /etc/NetworkManager/system-connections/*"
>>
>> ...but that will spawn a dom0 confirmation dialogue that I'd rather avoid 
>> (after all, dom0 is initiating the copy).
>>
>> I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I don't 
>> want to trust sys-net to initiate this copy on its own.
>>
>> Is there any way to directly copy files from one VM to another, executed 
>> directly from dom0?
>>
> 
> Not sure if it's the best solution, but this should work for avoiding
> prompt (briefly tested):
> 
> for i in $(qvm-run -a -p -u root sys-net "ls
> /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root "cat
> /etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm
> sys-net-profiles $i; done
> 

Oops small typo (forgot to name "sys-net" one time). Fixed:

for i in $(qvm-run -a -p -u root sys-net "ls
/etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root
sys-net "cat /etc/NetworkManager/system-connections/$i" > $i;
qvm-move-to-vm sys-net-profiles $i; done

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/f9639ac1-bbcf-bd7a-5cb5-01edf539ad11%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Copying between VMs from dom0

2017-06-28 Thread qubenix
wordswithn...@gmail.com:
> I want to copy network connection profiles from sys-net to sys-net-profiles 
> as my computer shuts down.
> 
> I'm creating a bash script in dom0 to help with this.
> 
> I could use 
> 
> qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles 
> /etc/NetworkManager/system-connections/*"
> 
> ...but that will spawn a dom0 confirmation dialogue that I'd rather avoid 
> (after all, dom0 is initiating the copy).
> 
> I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I don't 
> want to trust sys-net to initiate this copy on its own.
> 
> Is there any way to directly copy files from one VM to another, executed 
> directly from dom0?
> 

Not sure if it's the best solution, but this should work for avoiding
prompt (briefly tested):

for i in $(qvm-run -a -p -u root sys-net "ls
/etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root "cat
/etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm
sys-net-profiles $i; done

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/624a9c33-920e-412b-9b95-62351ce4825b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Can't install windows-tools, following docs.

2017-06-25 Thread qubenix
17:24]i410: Variable:
WixBundleOriginalSourceFolder = D:\
[0AA0:0AA4][2017-06-25T18:17:24]i410: Variable: WixBundleProviderKey =
{893ba9c4-6627-45b2-adb5-52faf393dccc}
[0AA0:0AA4][2017-06-25T18:17:24]i410: Variable:
WixBundleRollbackLog_qubes_tools_WIN7x64_3.2.2.3.msi =
C:\Users\IEUser\AppData\Local\Temp\Qubes_Windows_Tools_3.2.2.3_20170625181436_1_qubes_tools_WIN7x64_3.2.2.3.msi_rollback.log
[0AA0:0AA4][2017-06-25T18:17:24]i410: Variable: WixBundleTag =
[0AA0:0AA4][2017-06-25T18:17:24]i410: Variable: WixBundleVersion = 3.2.2.3
[0AA0:0AA4][2017-06-25T18:17:24]i007: Exit code: 0x1, restarting: No
```

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/ebb549fb-40d2-b9f3-eded-01a55e3e34fa%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Xen high CPU usage, but nothing is running in the VM

2017-06-18 Thread qubenix
'Vincent Adultman' via qubes-users:
> This happens to me sometimes on the current Xen/Linux versions. When I
> look at top in the offending VM its "kswapd" that has gone berserk.
> 
> --
> 
> Chris Laprise, tas...@openmailbox.org
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
> 
> --
> I can confirm I've also experienced this with kswapd in either sys-net or 
> sys-firewall, can't remember which. Only way around it I found was to reboot 
> the VM.
> 

I have also experience with kswapd going crazy in a Debian vm with
intense I/O and CPU. Kswapd persisted to rock the cpu even after all the
software was done, for about 10 minutes, until I shutdown the vm. Seems
to be a rare condition though because I experience it only 1/50 times
with this vm.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/76474d76-e39b-9ea0-83e6-77a81cc2538e%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL MSI Mobo, Intel CPU

2017-06-13 Thread qubenix
Hardware:

MOBO: MSI Z170I Gaming Pro AC LGA 1151 MS-7980
CPU: Intel 6th Gen Skylake i7-6700K
TPM: MSI 914-4136-103 dTPM 1.2
RAM: G.Skillz Ripjaws V DDR4 2400

---

Notes:

- AEM works.

- Have to switch boot order, take out "UEFI" options.

- No sys-net nm-applet after firstboot. On next boot applet was there.

---

Attached are the reports. Support report is encrypted to Qubes Devs:
ADW, JR, and MM.

Thank you to all devs and everyone on this list. My favorite host OS
and a very helpful community.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/2babbd44-ffb5-efdc-93b4-f4262629dea2%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
-BEGIN PGP MESSAGE-

hQIMAyyYz3tWP+oNAQ/+M7zYuSE9fMAn/VLngzNOC0pDpfPSX2jFj/LhrrbsXJzz
mqSKV034otweFDnRx1hFNfQT68xfFSJwmPUJKvBf2pxOtZyGRaK4pdOgWGgq1nO7
m/nRiMCmX5HcuAeB9F+6jyOR2oK8YObK3X3L/xd5g0EfWAe1V42pqPTTkvhmGp5h
xHi5FFgp7ayIPg+W44o7gdIsoAYGKmnJiaW/p+JiFvX7KdvjH2C1DKYshtJdGHxI
LNI7a9Nu15DdpFJHlVyTWgdcka0D5Lxy4fzvx7poQgNvMBZ0ZhR1YYgAdlHwoume
CGE9pCM1iLYCZkzX9vgbEaOWvmazryyo4cxbUW1+9eFUSWGUhz+KwM8Js7R42sfh
RiKIYP0CiyB3nzAf0telDfLut2eT8t6SA1w/VHQRGkot4aXftSCKhs4gXV0jYA+N
2AIZIhq78/ou2N+5hC282i9NofF4ZJJyj2A30RQJ/mSPeitN2hPcj2lwNhTQ8P3U
eKJr6vcD4j8AZMVSJkzzvAC7ZY6pnZ/JV2r5wbS+ZDG9NnmnxpoURbWmF2OdaElB
LDxFJblQBIaOlzsj5KmSVH94fcbaNhZHxaWBTvlDWDIC/vPmGFYzcu1HEiU/aQYz
l99xsZyM8pvKnktmYsjORLaEUuvNyGDcawoMxABgvrqKRyxW+qeDpHRfyh0G8ASF
AQwDqH2PP4A1NFQBCACh69jOT11gJaZxRaZkE3K3RXmJhqx+YF3pQKo+BqdIHZMd
DMIUmFTavuUl1jFpYjght/VWpUubSYP4t9YesobsihJKzdbvMfMa8BKCS295qUX6
oHwqkSW4wA6f2JgLSo4LpYeks5QomY4i1nPsGBlqu37y0LiaTQI7/rkyLhIjw0/V
5GInTTcFLEUye7ozPBOPfze41F5rTYlEpiYDyOyItOtx50MtjO5Cudx+vRilPj6C
FkmaKxvsQf0jINfOcSYXYcvpfWVSUNwxsZF2AXg4tU/zH+4vzsBD9Y5GyDomZYng
Sv2yAJD2PN05nTC7UuE2M7Ez1guN01k4kM0g9F0xhQIMA908wW+lbEkbARAA4f60
s+Db6oJjQ+exNklJUW7UnG5EATtTx9aiS8DBu0DBNW4jxObGOWFhcRxJ4HPbR79F
MYQt0fLhHlidGIcaMQ2ZhWNpXvDL7BsdF7XXKjcXn4CEMHD8dNJ/F5Vw81MuAHLH
FVoNiYzayxEAJfKuNqmnCVfoTs4W+z0fXKRLhmq+MTV2V+IgGk9+dmLWKr+5QXhO
WParx7DmfvGvVXTfpxR1y19N9TduSc2CdXBbH6oFrXBKatXdnSbCWpKLvWRvkwgY
f+2ebK8v/zGGF3xxRt/KZAaGHSNjMB+Sc+KTkkPxyO1w7OxOfmRwwVKXa6BbHIMA
fs46aLBo1rLSQlfhFpAQOcIv2PUtWr9kptaVirX59zobEXyhlyx3OLhqiZsa2a3n
bvbonh8GZuR9bxHyYsBCF3/yJz20v5FsBtEO6uAz623JWNh83v3bIzZZdP0P6++4
+N74grZXm/Im6fShCmsERz4zhZY4dRcsdaWNTPHosaNVopUfYMyYC/97VJdkH7sB
K4OjIQMXN8Iu/YBtT+746ehO4SScHTEeG1YGOISHUtJDLCfT9uDcznKygUsTb7Lk
G+94D6VHt4DDFkcPoLbBMiBbbTvLE1DtbjUSsE/fmGscb+l3dItaKJ2qWyvAkgvc
uQPYfNo+wNG1c5U7MCeBEyGtfLUbjIE02C8yHRHS/wAAJwwBT1pVMaf0jyVblSxR
AccJYgo+MtF5eQoXVowNwqUGjGX8OxPiaaK/MqUFdhhXqaYr6nSajKNT5BTmXakK
dIjqgO5B0oIZOJwJDYme3LK/jWPQ023ntBs1YkkNXjDv71m2HBZ06AvOYvZ99cb5
74yCtszu+HCin2tGbjq+I29DmODWi2+caXiHkW/+4rNWTEKFm5aLf1ZrWKV57Rac
K87+F2Og+P3qfjBOnIMjVSu5maiQZC3PIhm0d75Zn05Ugzre+Xk++7yVbbb6I9RY
SPBTwTmk9QCZSpHVeQ5I6qRZVGJHEgO0ZHDJeSszhyB8RfSQ87XcFD6w+c5W6McJ
9uAYXHNEWpm2MmFQVQR41lQsJaVA2P2h2sA91RIdRbAIfJTnOYueHMS3N+hnLwJl
Pa2yIolRkCK+5CEoLTtjep1eCq6nVeH0KiGwHEzrAbJ8snFR3ozkciCQgvFogUFY
M0uzumFI/YPRk6lMY1TEm+T7jPrmDt8T/Qc9I5LL4k/9Kx7uj1O8tch42ltp8wuy
iOdSANj8jXzWZqHg6zX/YHPvO6zRcwl53UXK/6nZIJo63wDUlHXto+N9px1OnnFK
b4sm/NzZhcmzl2TGoY9vNSQ+tK9oOjBmFSwKjH8dtyT9fbzpZHHfiTO6z8DK7SgK
CH1K0vyIqXKeH5yT41wd08hi/r15NZsrkyCwShLfYClE1wNM8j2GYrEhh4G0od8x
Tp8mAjD2z7eF2pPWL5FWAfixTsUB3JuYLQdK2X/2OLDPxUDrfXJ7YMQWWGgZ/kP/
+Z+3zMfLDfQtDQZ9OqxyAtMyVon5/+j8bte883lDfB1elGtJ7jb18CPcdvzITq++
+Df2N5Z8y+ErqT7kvCIkDgVvvLV4DByY+uwYcvZd/Zw/yQGIOwAUbUQl7fgTla0W
kP4Ma8Fs0Iqi1uYPSrgwSnaYi1nFKpgURDSN8vuz/hhc9SJF1LXbBlUYH351owv4
bKOY/ddZzP5nN2rzoegXwGNIhssqciKFtGXew+DxMX7w7BTa0n/qv31e+BbE1ywh
4Ap4ONeJdu9igm7JgM9R6xxaegRsHab6bWwfzfwQzE08cWbpR1hhMUGTuY1osYIS
IUSKirpEHlmBqbs5eqiPNuzwDNXcRBvgD2lF0sMx5VvsI/P5FFju9ELVTSslY3Pg
gJqVeDODybX0eBJahqxqnktx58YwqCnvTmFRNcxFmOP9JMyRlXbCKlBC600FbUov
8DWypnAEAwlpnFXUX8oNAgOdoaWvXhghJpx1LFVZBYhly0pjpTpbQuWzxrySkfj7
icxXifJno2EUFTYeNjjSWFPxpOQVLqQZg4vVkakLHbDG+qv2kKjjMYVZivqwzcUU
ENf4+nl3b03qo0tC5hpfdha0qsYhmb422ar0fWRrJxSfTaY7AGpvicDjzIRQMblS
Yry3jvEAn2uS+t7adX4K+/lsgz/JB8hWw8rHlqkLL0GN1BU07RSv+fxnAzHeR3So
4IBhZBPHrCJ4UiaBfgb2vInrEqh8meXU6bWt+H4dx1LUu2q2npv3pgOsQpHKopwM
FtumI39wxThO0xW9se9PEPyg+uSXbIKHCChH9OcSb+Ki0jUv6FXxden+RLitOr1d
A9mx4H/i8FMX6ztp2TtXhz+Aq52yy/7e9v5GGXj8gh/zs1JzuPK84eceLw5CSCjK
KuinzWl5AyAXnY/a1kPHY33rijP59F48CCRBwZSHnQDrpwpxDZg15/ySXom+Jvqv
V0duDtts7XedGV2wjfASEfqoGAuRuyx45fcBVlxJ+a+tqg+98J59jFUk1rFKbS+M
VHwZYvqlrsgH1jI7NC2UsB+rz7U/CM7y/Ox39sAGd+2gS32uEVOc/yEaa7JWok6F
ja43e+j9GLmlDrdS8eN/G6O3iHu4okZYiVYS1ogJA/hG16ZZgRtu3fBpntEn4QUz
1/a0FuCGCYeOh3YvU+2XBtXkXixvYWd3emJEDewPVdpsm7gMGqCtJ+0CtAjC7n4B
rZASSsICwLwi1bvH1X1V3WR1XWdLI+l7rXtB2bvLMyTK

Re: [qubes-users] Anyone got a intel z270 motherboard to work with Qube os

2017-06-12 Thread qubenix
carrefamilyhomes...@gmail.com:
> On Saturday, June 10, 2017 at 8:35:52 PM UTC-4, qubenix wrote:
>> carr...@gmail.com:
>>> Hi,
>>>
>>> My motherboard broke and I need to rebuild my computer. I am looking to get 
>>> something that will last forever and has all the bells and whistles. I am 
>>> currently looking at the Asus prime 
>>> z270-K(https://www.newegg.com/Product/Product.aspx?Item=N82E16813132938=1).
>>>  Has anyone gotten qube os to work on this board? 
>>>
>>> Has anyone gotten qube os on any z270? Any help would be really 
>>> appreciated. 
>>>
>>
>> I just built a rig around z170 board. Everything is working fine so far.
>> I'll be doing an HCL once my tpm module arrives.
>>
>> -- 
>> qubenix
>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> 
> Which model motherboard? What is HCL? 
> 

It is a MSI Z170I Gaming Pro AC Mini-ITX (MS-7980). HCL is hardware
compatibility list: https://qubes-os.org/hcl.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/68878165-6f5e-5697-a710-e1885176aed2%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Anyone got a intel z270 motherboard to work with Qube os

2017-06-10 Thread qubenix
carr...@gmail.com:
> Hi,
> 
> My motherboard broke and I need to rebuild my computer. I am looking to get 
> something that will last forever and has all the bells and whistles. I am 
> currently looking at the Asus prime 
> z270-K(https://www.newegg.com/Product/Product.aspx?Item=N82E16813132938=1).
>  Has anyone gotten qube os to work on this board? 
> 
> Has anyone gotten qube os on any z270? Any help would be really appreciated. 
> 

I just built a rig around z170 board. Everything is working fine so far.
I'll be doing an HCL once my tpm module arrives.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/5d28c161-a54b-178a-c301-ec9ea90bad80%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: "root=/dev/mapper/dmroot crashed"

2017-05-18 Thread qubenix
devr...@gmail.com:
> Hmm.  Two devices with the same major:minor numbers? /dev/mapper/dmroot & 
> /dev/dm-0
> 
> /dev/mapper/dmroot does not appear in Dom0, nor does any error appear in 
> journalctl.  I do find that device in sys-{net,firewall,whonix,usb} and in 
> those cases it always appears as:
> 
> ls -l /dev/mapper/dmroot
> brw-rw 1 root disk 251, 0 May 13 20:11 /dev/mapper/dmroot
> 
> lsblk /dev/xvdc
> NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> xvdc   202:32   1 11.5G  0 disk 
> ├─xvdc1202:33   11G  0 part [SWAP]
> └─xvdc2202:34   1 10.5G  0 part 
>   └─dmroot 251:00   10G  0 dm   /
> 
> In each of these VM's I find only one error related to dmroot.  On a single 
> bootup (but not subsequently) and in all the VM's:
> 
> May 13 02:56:21 fedora-25 systemd-udevd[7757]: conflicting device node 
> '/dev/mapper/dmroot' found, link to '/dev/dm-0' will not be created
> 
> In all those VM's I also find:
> 
> ls -l /dev/dm-0
> brw-rw 1 root disk 251, 0 May 13 20:11 /dev/dm-0
> 
> Notice the same major:minor numbers as /dev/mapper/dmroot
> 

I'm also getting this error from my usb vm on startup. It has a Fedora24
template. The template is untouched from initial Qubes install, aside
from updates via qubes-vm-r3.2-current-testing repo.

For me the issue just started today for no obvious reason.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/f04ec9b9-7990-5aa8-3e10-3008c836a208%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Onion site stuck in redirect loop

2017-05-09 Thread qubenix
his page (maybe more?): http://qubesos4z6n4.onion/doc/firewall/
gets stuck in a redirection loop.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/68566c1c-b22e-74fd-4dfd-82d1545c9a85%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

2017-04-15 Thread qubenix
Reg Tiangha:
> On 04/15/2017 01:06 PM, qubenix wrote:
>> peter...@hushmail.com:
>>> Is there a script to randomize hostname on each boot?
>>>
>> I think blank hostname is better than randomized. How would it be
>> randomized: dictionary words, rng, cycling popular hostnames, etc.? Your
>> randomization method may make you more identifiable than blank.
>>
> 
> Dumb question here, but what's the difference between commenting the
> line out of the .conf file vs explicitly setting it with a blank
> hostname? Does it not result in the same thing? Or does simply
> commenting it out still risk sending out a hostname of some kind in some
> circumstances?
> 
> 
I've got it commented out and it has always been blank on my tests.

--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/cd0a1ea0-6cfe-c28a-fc9a-728b2c800f4f%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

2017-04-15 Thread qubenix
peter...@hushmail.com:
> 
> Is there a script to randomize hostname on each boot?
> 
I think blank hostname is better than randomized. How would it be
randomized: dictionary words, rng, cycling popular hostnames, etc.? Your
randomization method may make you more identifiable than blank.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/f15d3d7e-cf63-f094-6a9e-dd5872dedb04%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

2017-04-12 Thread qubenix
cooloutac:
> On Wednesday, April 12, 2017 at 10:55:08 AM UTC-4, qubenix wrote:
>> Unman:
>>> On Tue, Apr 11, 2017 at 06:20:38AM -0700, Dominique St-Pierre Boucher wrote:
>>>> On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote:
>>>>> qubenix:
>>>>>> Andrew David Wong:
>>>>>>> On 2017-04-09 15:25, Joonas Lehtonen wrote:
>>>>>>>> Hi,
>>>>>>>
>>>>>>>> if you setup MAC randomization via network manager in a debian 9
>>>>>>>> template as described here:
>>>>>>>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>>>>>>>> you still leak your hostname.
>>>>>>>
>>>>>>>> Once your MAC address is randomized you might also want to prevent the
>>>>>>>> disclosure of your netvm's hostname to the network, since "sys-net"
>>>>>>>> might be a unique hostname (that links all your random MAC addresses 
>>>>>>>> and
>>>>>>>> the fact that you likely use qubes).
>>>>>>>
>>>>>>>> To prevent the hostname leak via DHCP option (12):
>>>>>>>> - start the debian 9 template
>>>>>>>> - open the file /etc/dhcpd/dhclient.conf
>>>>>>>> - in line number 15 you should see "send host-name = gethostname();"
>>>>>>>> - comment (add "#" at the beginning) or remove that line and store the 
>>>>>>>> file
>>>>>>>> - reboot your netvm
>>>>>>>
>>>>>>>> I tested the change via inspecting dhcp requests and can confirm that
>>>>>>>> the hostname is no longer included in dhcp requests.
>>>>>>>
>>>>>>>
>>>>>>> Thanks. Added as a comment:
>>>>>>>
>>>>>>> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Nice. I was just thinking about this after spending some time on my
>>>>>> routers interface. Thanks for the post!
>>>>>>
>>>>>
>>>>> After testing this, 'sys-net' still shows up on my router interface.
>>>>>
>>>>> -- 
>>>>> qubenix
>>>>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
>>>>
>>>> Did the same test and got the same result.
>>>>
>>>> Anyone has a solution? I can always change my hostname for something else, 
>>>> but I would prefer not sending the hostname or finding a way to randomize 
>>>> it!!!
>>>>
>>>> Dominique
>>>>
>>>
>>> Strange, because those instructions are standard for removing the
>>> hostname - I set it as blank, rather than commenting out. If you sniff
>>> the traffic you will see that the hostname is indeed no longer sent.
>>>
>>> Why is it on your router interface?
>>> My guess is that your router is returning the hostname that it has
>>> associated with the MAC address. I've seen this happen when changing
>>> hostname, and the DHCP server returns the *old* hostname as part of
>>> the DHCP exchange. If you reboot the router and test again, you may find
>>> that the issue goes away.
>>
>> Confirmed. Router was "guessing" that I was 'sys-net', but not from MAC
>> (which is randomized). I believe it was using process of elimination
>> based on stored device hostnames (this is not public, devices are pretty
>> static). Since restarting the router, it give my pc the hostname of a
>> device which connected automatically to it (the only one it had to
>> "guess" from).
>>
>>>
>>> You could, of course, set a random hostname from rc.local on each boot of
>>> sys-net.
>>>
>>> unman
>>>
>>>
>>
>>
>> -- 
>> qubenix
>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> 
> But why use dhcp if its a static home connection?  I feel that is a security 
> risk for other reasons and always disable it.
> 
I haven't looked into the security risk for dhcp connection. I intend to
look into it and adjust accordingly. Thanks for the suggestion.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/bb62f68f-75e4-677d-462d-44b0872d72ec%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

2017-04-12 Thread qubenix
Unman:
> On Tue, Apr 11, 2017 at 06:20:38AM -0700, Dominique St-Pierre Boucher wrote:
>> On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote:
>>> qubenix:
>>>> Andrew David Wong:
>>>>> On 2017-04-09 15:25, Joonas Lehtonen wrote:
>>>>>> Hi,
>>>>>
>>>>>> if you setup MAC randomization via network manager in a debian 9
>>>>>> template as described here:
>>>>>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>>>>>> you still leak your hostname.
>>>>>
>>>>>> Once your MAC address is randomized you might also want to prevent the
>>>>>> disclosure of your netvm's hostname to the network, since "sys-net"
>>>>>> might be a unique hostname (that links all your random MAC addresses and
>>>>>> the fact that you likely use qubes).
>>>>>
>>>>>> To prevent the hostname leak via DHCP option (12):
>>>>>> - start the debian 9 template
>>>>>> - open the file /etc/dhcpd/dhclient.conf
>>>>>> - in line number 15 you should see "send host-name = gethostname();"
>>>>>> - comment (add "#" at the beginning) or remove that line and store the 
>>>>>> file
>>>>>> - reboot your netvm
>>>>>
>>>>>> I tested the change via inspecting dhcp requests and can confirm that
>>>>>> the hostname is no longer included in dhcp requests.
>>>>>
>>>>>
>>>>> Thanks. Added as a comment:
>>>>>
>>>>> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628
>>>>>
>>>>>
>>>>
>>>> Nice. I was just thinking about this after spending some time on my
>>>> routers interface. Thanks for the post!
>>>>
>>>
>>> After testing this, 'sys-net' still shows up on my router interface.
>>>
>>> -- 
>>> qubenix
>>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
>>
>> Did the same test and got the same result.
>>
>> Anyone has a solution? I can always change my hostname for something else, 
>> but I would prefer not sending the hostname or finding a way to randomize 
>> it!!!
>>
>> Dominique
>>
> 
> Strange, because those instructions are standard for removing the
> hostname - I set it as blank, rather than commenting out. If you sniff
> the traffic you will see that the hostname is indeed no longer sent.
> 
> Why is it on your router interface?
> My guess is that your router is returning the hostname that it has
> associated with the MAC address. I've seen this happen when changing
> hostname, and the DHCP server returns the *old* hostname as part of
> the DHCP exchange. If you reboot the router and test again, you may find
> that the issue goes away.

Confirmed. Router was "guessing" that I was 'sys-net', but not from MAC
(which is randomized). I believe it was using process of elimination
based on stored device hostnames (this is not public, devices are pretty
static). Since restarting the router, it give my pc the hostname of a
device which connected automatically to it (the only one it had to
"guess" from).

> 
> You could, of course, set a random hostname from rc.local on each boot of
> sys-net.
> 
> unman
> 
> 


-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/9245f24a-f51e-1ea8-10d1-55d92abfd6c8%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

2017-04-10 Thread qubenix
qubenix:
> Andrew David Wong:
>> On 2017-04-09 15:25, Joonas Lehtonen wrote:
>>> Hi,
>>
>>> if you setup MAC randomization via network manager in a debian 9
>>> template as described here:
>>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>>> you still leak your hostname.
>>
>>> Once your MAC address is randomized you might also want to prevent the
>>> disclosure of your netvm's hostname to the network, since "sys-net"
>>> might be a unique hostname (that links all your random MAC addresses and
>>> the fact that you likely use qubes).
>>
>>> To prevent the hostname leak via DHCP option (12):
>>> - start the debian 9 template
>>> - open the file /etc/dhcpd/dhclient.conf
>>> - in line number 15 you should see "send host-name = gethostname();"
>>> - comment (add "#" at the beginning) or remove that line and store the file
>>> - reboot your netvm
>>
>>> I tested the change via inspecting dhcp requests and can confirm that
>>> the hostname is no longer included in dhcp requests.
>>
>>
>> Thanks. Added as a comment:
>>
>> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628
>>
>>
> 
> Nice. I was just thinking about this after spending some time on my
> routers interface. Thanks for the post!
> 

After testing this, 'sys-net' still shows up on my router interface.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/e43a76ea-eba3-9aba-f127-eec495a7fcee%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

2017-04-10 Thread qubenix
Andrew David Wong:
> On 2017-04-09 15:25, Joonas Lehtonen wrote:
>> Hi,
> 
>> if you setup MAC randomization via network manager in a debian 9
>> template as described here:
>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>> you still leak your hostname.
> 
>> Once your MAC address is randomized you might also want to prevent the
>> disclosure of your netvm's hostname to the network, since "sys-net"
>> might be a unique hostname (that links all your random MAC addresses and
>> the fact that you likely use qubes).
> 
>> To prevent the hostname leak via DHCP option (12):
>> - start the debian 9 template
>> - open the file /etc/dhcpd/dhclient.conf
>> - in line number 15 you should see "send host-name = gethostname();"
>> - comment (add "#" at the beginning) or remove that line and store the file
>> - reboot your netvm
> 
>> I tested the change via inspecting dhcp requests and can confirm that
>> the hostname is no longer included in dhcp requests.
> 
> 
> Thanks. Added as a comment:
> 
> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628
> 
> 

Nice. I was just thinking about this after spending some time on my
routers interface. Thanks for the post!

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/913fb528-2469-976e-4e2c-2c276864727c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Pandavirtualization: Exploiting the Xen hypervisor

2017-04-07 Thread qubenix
Wondering if the list has seen this yet:
https://googleprojectzero.blogspot.com/2017/04/pandavirtualization-exploiting-xen.html

PoC on Qubes 3.2.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/9c3e200b-1044-d1a8-9075-3779e110503f%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Qubes manager not showing changes, etc.

2017-02-16 Thread qubenix
Since the upgrade to version 3.2.8-1.fc23 of qubes manager I've been
having some issues.

1. Changes made to existing VMs or newly created VMs do not show in the
manager until I restart Qubes. Restarting only the manager does not help.

2. I have very often yellow state indicators while the VM is running.
`qvm-ls` shows state as "Running" and everything works normal in the VM
during yellow indicator. Restarting the VM usually fixes this issue.
I've noticed that this happens more often when I have many VMs starting
together, but not dependant on each other (to rule out race condition of
two VMs trying to start same proxy vm for example).

It seems others were having these issues before the upgrade, and since I
haven't noticed any complaints. My experience was the opposite. I had no
issues previous to this upgrade.

Please let me know any other info/logs that may be helpful.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/13162574-5746-58bf-7171-9658834d10b1%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kali TemplateVM terminal etc. do not open

2016-12-16 Thread qubenix
Bernd Kohler:
> Hi @ all,
> 
> I made a clone of my debian-8 TemplateVM, renamed it and replaced the 
> apt-sources with the kali-ones. After that I installed some kali- 
> paket-groups.
> 
> Everything was fine until last week. After some updates I could start the 
> TemplateVM but wasn't able to start/run any programm
> 
> For example opening a Gnome terminal does not work.
> 
> In case someone here has the solution I am very interested, but giving me a 
> hint, where and how to debug will make me happy too ;)
> 
> thx and regards
> 
> Bernd
> 
> 
> 

See here for details:
https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com

In short you need to:

- Change qubes repo to `stretch-testing`
- update and dist-upgrade your template

If you run into problems, all the answers should be in that thread I linked.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/68bffa26-b1e3-2b33-3140-2f08995a896a%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: debian-9 sys-net, random MAC buggy

2016-12-16 Thread qubenix
Chris Laprise:
> On 12/15/2016 01:58 PM, Reg Tiangha wrote:
>> On 12/15/2016 11:50 AM, qubenix wrote:
>>> I've used the docs[1] to randomize my MAC on sys-net with debian-9 as
>>> it's template. At first everything was working normal, but I've noticed
>>> now that my MAC is only randomized until I connect to a network. At that
>>> point it switches back to the original MAC. Anyone else experiencing
>>> this?
>>>
>>> Second issue is that it seems my eth0 is never randomized. Any users
>>> with the same experience?
>>>
>>> [1] https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>>>
>> I've had that happen ever since I tried it so I just assumed it was a
>> bug or a hardware issue that doesn't allow my wifi adapter to change. If
>> there's a workaround or an extra package to install to make it work
>> properly, I'd love to hear it. I get the same issue with NM on Debian 9
>> or Fedora 25, as well as the macchanger method. It does scramble the MAC
>> address when it's not connected to an access point, but reverts to the
>> original one once it connects to a network.
>
>
> The main issue here is that the correct config keyword
> "cloned-mac-address" reverted to an incorrect (non-)keyword
> "assigned-mac-address" that was used in an earlier version (see
>
https://github.com/tasket/qubes-doc/commit/27dcc6f142d627293d7788cbd5610b4f6b4f2df5
> ).
>
> Somehow this got changed back to the original, mistaken keyword here:
>
https://github.com/QubesOS/qubes-doc/commit/a9a82bedf092eec13e774dc50cbc6f83f0ef2182
>
>
> The "assigned-mac-address" is a property for NM's dbus interface ...not
> in the config parser where "cloned-mac-address" is used (see gnome.org
> link below).
>
> --
>
> With that said, there is an actual NM bug where it ignores randomization
> settings when connecting to an AP. This bug bit me and the workaround
> was to use a newly-created netVM instead of existing one so that old NM
> connection data was not present in the new configuration. That's why the
> instructions say to create a new netVM.
>
>
https://mail.gnome.org/archives/networkmanager-list/2016-October/msg00019.html
>
>
>
> Chris
>

Ah, that was my mistake/commit. I apologize, I did not see this
documented before. Thank you for helping me to realize this confusing
situation.

The worst part, really, is that the only place in the man pages where
random vs. stable is documented is in the section that specifies that
`cloned-mac-address` is deprecated!?! It would be really nice if this
were also doc'd in the `keyfile` or `ifcfg` pages. So now the Qubes docs
have to point to a page that is going to  recreate this situation over
again.

Relevant NetworkManager doc pages:

https://developer.gnome.org/NetworkManager/1.4/nm-settings.html
https://developer.gnome.org/NetworkManager/1.4/nm-settings-keyfile.html
https://developer.gnome.org/NetworkManager/1.4/nm-settings-ifcfg-rh.html

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/73d2e3f7-3552-74e9-0a66-763ef72287e3%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template (and sub-vms) non interactive after package updates

2016-12-13 Thread qubenix
Boris Kourtoukov:
> On Tuesday, December 13, 2016 at 3:11:12 PM UTC-5, qubenix wrote:
>> Boris Kourtoukov:
>>> On Tuesday, December 13, 2016 at 2:49:23 PM UTC-5, qubenix wrote:
>>>> Boris Kourtoukov:
>>>>> This is similar to what happened with the Whonix discussion here: 
>>>>> https://groups.google.com/d/msg/qubes-users/IHhxklnCpYc/Wj2K5euVBAAJ
>>>>>
>>>>> I am getting to this point:
>>>>>
>>>>> ```
>>>>> ...
>>>>> Waiting for VM's qrexec agent...connected
>>>>> --> Starting Qubes GUId...
>>>>> Connecting to VM's GUI agent: .connected
>>>>> --> Sending monitor layout...
>>>>> --> Waiting for qubes-session...
>>>>> ```
>>>>>
>>>>> And then it waits forever. Attempting to open an app in any of the sub 
>>>>> VMs fails with no (visual) feedback. 
>>>>>
>>>>> The Debian TemplateVM starts and runs. And if I get into it via:
>>>>>
>>>>> `virsh -c xen:/// console debian-9`
>>>>>
>>>>> I am able to run commands as root. 
>>>>>
>>>>> Unfortunately doing a dist-upgrade and checking for broken/unmet 
>>>>> dependencies resulted in nothing (dist-upgrade updated 0 packages.) 
>>>>> Everything appears to be installed correctly. 
>>>>>
>>>>> (I did a check with `debsums --changed` as well. it came up empty.)
>>>>>
>>>>> Any thoughts on what else to debug?
>>>>>
>>>> >From this discussion:
>>>> https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com
>>>>
>>>> Start your template from gui or dom0 cli as you did. When you get to:
>>>>
>>>>> --> Waiting for qubes-session...
>>>>
>>>> `Ctrl-c` to stop the endless wait you described. Then (still from dom0) do:
>>>>
>>>> qvm-run -p -u root debian-9 "apt-get update && apt-get install -t
>>>> stretch xserver-xorg-core -y && apt-get dist-upgrade -y"
>>>>
>>>> Restart your template and see that you get display again, should fix it.
>>>>
>>>> -- 
>>>> qubenix
>>>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
>>>
>>> It said the package was already at latest version. I proceeded to 
>>> `--reinstall` it and still no luck. Still sticks on waiting for 
>>> qubes-session.
>>>
>> What version do you have installed?
>>
>> -- 
>> qubenix
>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> 
> 2:1.19.0-2
> 
Ah, I think you need the repo `stretch-testing` from qubes. So do:

qvm-run -u root debian-9 'echo "deb [arch=amd64]
http://deb.qubes-os.org/r3.2/vm stretch-testing main" >>
/etc/apt/sources.list.d/qubes-r3.list'
qvm-run -p -u root debian-9 "apt-get update && apt-get dist-upgrade -y"

Hopefully that will fix it. Sorry I forgot the repo had to be changed.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/d7d454fc-b75e-4670-0fa4-b1816e77b398%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template (and sub-vms) non interactive after package updates

2016-12-13 Thread qubenix
Boris Kourtoukov:
> On Tuesday, December 13, 2016 at 2:49:23 PM UTC-5, qubenix wrote:
>> Boris Kourtoukov:
>>> This is similar to what happened with the Whonix discussion here: 
>>> https://groups.google.com/d/msg/qubes-users/IHhxklnCpYc/Wj2K5euVBAAJ
>>>
>>> I am getting to this point:
>>>
>>> ```
>>> ...
>>> Waiting for VM's qrexec agent...connected
>>> --> Starting Qubes GUId...
>>> Connecting to VM's GUI agent: .connected
>>> --> Sending monitor layout...
>>> --> Waiting for qubes-session...
>>> ```
>>>
>>> And then it waits forever. Attempting to open an app in any of the sub VMs 
>>> fails with no (visual) feedback. 
>>>
>>> The Debian TemplateVM starts and runs. And if I get into it via:
>>>
>>> `virsh -c xen:/// console debian-9`
>>>
>>> I am able to run commands as root. 
>>>
>>> Unfortunately doing a dist-upgrade and checking for broken/unmet 
>>> dependencies resulted in nothing (dist-upgrade updated 0 packages.) 
>>> Everything appears to be installed correctly. 
>>>
>>> (I did a check with `debsums --changed` as well. it came up empty.)
>>>
>>> Any thoughts on what else to debug?
>>>
>> >From this discussion:
>> https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com
>>
>> Start your template from gui or dom0 cli as you did. When you get to:
>>
>>> --> Waiting for qubes-session...
>>
>> `Ctrl-c` to stop the endless wait you described. Then (still from dom0) do:
>>
>> qvm-run -p -u root debian-9 "apt-get update && apt-get install -t
>> stretch xserver-xorg-core -y && apt-get dist-upgrade -y"
>>
>> Restart your template and see that you get display again, should fix it.
>>
>> -- 
>> qubenix
>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> 
> It said the package was already at latest version. I proceeded to 
> `--reinstall` it and still no luck. Still sticks on waiting for qubes-session.
> 
What version do you have installed?

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/6b8485a8-2ea7-4e92-3ca5-b84851d8d5a0%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template (and sub-vms) non interactive after package updates

2016-12-13 Thread qubenix
Boris Kourtoukov:
> This is similar to what happened with the Whonix discussion here: 
> https://groups.google.com/d/msg/qubes-users/IHhxklnCpYc/Wj2K5euVBAAJ
> 
> I am getting to this point:
> 
> ```
> ...
> Waiting for VM's qrexec agent...connected
> --> Starting Qubes GUId...
> Connecting to VM's GUI agent: .connected
> --> Sending monitor layout...
> --> Waiting for qubes-session...
> ```
> 
> And then it waits forever. Attempting to open an app in any of the sub VMs 
> fails with no (visual) feedback. 
> 
> The Debian TemplateVM starts and runs. And if I get into it via:
> 
> `virsh -c xen:/// console debian-9`
> 
> I am able to run commands as root. 
> 
> Unfortunately doing a dist-upgrade and checking for broken/unmet dependencies 
> resulted in nothing (dist-upgrade updated 0 packages.) Everything appears to 
> be installed correctly. 
> 
> (I did a check with `debsums --changed` as well. it came up empty.)
> 
> Any thoughts on what else to debug?
> 
>From this discussion:
https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com

Start your template from gui or dom0 cli as you did. When you get to:

> --> Waiting for qubes-session...

`Ctrl-c` to stop the endless wait you described. Then (still from dom0) do:

qvm-run -p -u root debian-9 "apt-get update && apt-get install -t
stretch xserver-xorg-core -y && apt-get dist-upgrade -y"

Restart your template and see that you get display again, should fix it.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/83dc210c-46ba-348d-5a16-c2d9e02c505a%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template (and sub-vms) non interactive after package updates

2016-12-13 Thread qubenix
Boris Kourtoukov:
> This is similar to what happened with the Whonix discussion here: 
> https://groups.google.com/d/msg/qubes-users/IHhxklnCpYc/Wj2K5euVBAAJ
> 
> I am getting to this point:
> 
> ```
> ...
> Waiting for VM's qrexec agent...connected
> --> Starting Qubes GUId...
> Connecting to VM's GUI agent: .connected
> --> Sending monitor layout...
> --> Waiting for qubes-session...
> ```
> 
> And then it waits forever. Attempting to open an app in any of the sub VMs 
> fails with no (visual) feedback. 
> 
> The Debian TemplateVM starts and runs. And if I get into it via:
> 
> `virsh -c xen:/// console debian-9`
> 
> I am able to run commands as root. 
> 
> Unfortunately doing a dist-upgrade and checking for broken/unmet dependencies 
> resulted in nothing (dist-upgrade updated 0 packages.) Everything appears to 
> be installed correctly. 
> 
> (I did a check with `debsums --changed` as well. it came up empty.)
> 
> Any thoughts on what else to debug?
> 
>From this discussion:
https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com

Start your template from gui or dom0 cli as you did. When you get to:

> --> Waiting for qubes-session...

`Ctrl-c` to stop the endless wait you described. Then (still from dom0) do:

qvm-run -p -u root debian-9 "apt-get update && apt-get install -t
stretch xserver-xorg-core -y && apt-get dist-upgrade -y"

Restart Template and/or AppVMs based from it. That should fix things in
your TemplateVM and AppVMs.


-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/bac730a1-6e49-0ee2-8b85-b3c84075ae39%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kali VM no longer responding

2016-12-12 Thread qubenix
qubenix:
> qubenix:
>> Marek Marczykowski-Górecki:
>>> On Mon, Dec 12, 2016 at 05:10:00PM +, qubenix wrote:
>>>> Marek Marczykowski-Górecki:
>>>>> Looks like this issue:
>>>>> https://github.com/QubesOS/qubes-issues/issues/2514
>>>>>
>>>>> Rebuilt package just uploaded to testing repository
>>>>> (qubes-gui-agent_3.2.10-2+deb9u1).
>>>>>
>>>>>
>>>
>>>> Doesn't seem to be fixed in stretch, stretch-testing, or
>>>> stretch-securitytesting yet.
>>>
>>>> ```
>>>> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
>>>> dist-upgrade -y"
>>>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>>>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>>>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>>>> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
>>>> Reading package lists...
>>>> Reading package lists...
>>>> Building dependency tree...
>>>> Reading state information...
>>>> Calculating upgrade...
>>>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>>>> [user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-gui
>>>> ii qubes-gui-agent 3.2.8+deb9u1 amd64 Makes X11 windows available to
>>>> qubes dom0
>>>> ```
>>>
>>> Interesting, I have qubes-gui-agent 3.2.11 already, from
>>> stretch-testing. Do you have some caching proxy in between?
>>>
>> At one point I was using Rustybirds update cache proxy, but I've since
>> switched back to a whonix-gw and unchecked "Allow connections to Updates
>> Proxy".
>>
>> I have two debian-9 templates, and they both were connected to update
>> cache and are now connected to whonix-gw. Here's the results from my two
>> debian-9 templates (one is using stretch-testing and
>> stretch-securitytesting the other has only stretch-testing although I
>> don't think that should matter):
>>
>> ```
>> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
>> dist-upgrade -y -V"
>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
>> Reading package lists...
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Calculating upgrade...
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> [user@dom0 ~]$ qvm-run -p d9-kali "sudo apt-get update && sudo apt-get
>> dist-upgrade -y -V"
>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>> Hit:5 http://deb.bitmask.net/debian stretch InRelease
>> Hit:4 http://archive-3.kali.org/kali kali-rolling InRelease
>> Reading package lists...
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Calculating upgrade...
>> The following packages have been kept back:
>>qubes-gui-agent (3.2.8+deb9u1 => 3.2.11-1+deb9u1)
>> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
>> [user@dom0 ~]$ qvm-run -p d9-kali "sudo aptitude dist-upgrade"
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Reading extended state information...
>> Initializing package states...
>> Building tag database...
>> The following NEW packages will be installed:
>>   xserver-xorg-input-qubes{ab} xserver-xorg-video-dummyqbs{ab}
>> The following packages will be upgraded:
>>   qubes-gui-agent
>> 1 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
>> Need to get 66.5 kB of archives. After unpacking 36.9 kB will be used.
>> The following packages have unmet dependencies:
>>  xserver-xorg-video-dummyqbs : Depends: xorg-video-abi-23 which is a
>> virtual package, provided by:
>> - xserver-xorg-core
>> (2:1.19.0-2), but 2:1.18.4-2 is installed
>>
>>Depends: xserver-xorg-core (>=
>> 2:1.18.99.901) but 2:1.18.4-2 is installed
>>  xserver-xorg-in

Re: [qubes-users] Kali VM no longer responding

2016-12-12 Thread qubenix
qubenix:
> Marek Marczykowski-Górecki:
>> On Mon, Dec 12, 2016 at 05:10:00PM +, qubenix wrote:
>>> Marek Marczykowski-Górecki:
>>>> Looks like this issue:
>>>> https://github.com/QubesOS/qubes-issues/issues/2514
>>>>
>>>> Rebuilt package just uploaded to testing repository
>>>> (qubes-gui-agent_3.2.10-2+deb9u1).
>>>>
>>>>
>>
>>> Doesn't seem to be fixed in stretch, stretch-testing, or
>>> stretch-securitytesting yet.
>>
>>> ```
>>> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
>>> dist-upgrade -y"
>>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>>> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
>>> Reading package lists...
>>> Reading package lists...
>>> Building dependency tree...
>>> Reading state information...
>>> Calculating upgrade...
>>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>>> [user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-gui
>>> ii qubes-gui-agent 3.2.8+deb9u1 amd64 Makes X11 windows available to
>>> qubes dom0
>>> ```
>>
>> Interesting, I have qubes-gui-agent 3.2.11 already, from
>> stretch-testing. Do you have some caching proxy in between?
>>
> At one point I was using Rustybirds update cache proxy, but I've since
> switched back to a whonix-gw and unchecked "Allow connections to Updates
> Proxy".
> 
> I have two debian-9 templates, and they both were connected to update
> cache and are now connected to whonix-gw. Here's the results from my two
> debian-9 templates (one is using stretch-testing and
> stretch-securitytesting the other has only stretch-testing although I
> don't think that should matter):
> 
> ```
> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
> dist-upgrade -y -V"
> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Calculating upgrade...
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> [user@dom0 ~]$ qvm-run -p d9-kali "sudo apt-get update && sudo apt-get
> dist-upgrade -y -V"
> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
> Hit:5 http://deb.bitmask.net/debian stretch InRelease
> Hit:4 http://archive-3.kali.org/kali kali-rolling InRelease
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Calculating upgrade...
> The following packages have been kept back:
>qubes-gui-agent (3.2.8+deb9u1 => 3.2.11-1+deb9u1)
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> [user@dom0 ~]$ qvm-run -p d9-kali "sudo aptitude dist-upgrade"
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Reading extended state information...
> Initializing package states...
> Building tag database...
> The following NEW packages will be installed:
>   xserver-xorg-input-qubes{ab} xserver-xorg-video-dummyqbs{ab}
> The following packages will be upgraded:
>   qubes-gui-agent
> 1 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
> Need to get 66.5 kB of archives. After unpacking 36.9 kB will be used.
> The following packages have unmet dependencies:
>  xserver-xorg-video-dummyqbs : Depends: xorg-video-abi-23 which is a
> virtual package, provided by:
> - xserver-xorg-core
> (2:1.19.0-2), but 2:1.18.4-2 is installed
> 
>Depends: xserver-xorg-core (>=
> 2:1.18.99.901) but 2:1.18.4-2 is installed
>  xserver-xorg-input-qubes : Depends: xorg-input-abi-24 which is a
> virtual package, provided by:
>  - xserver-xorg-core (2:1.19.0-2),
> but 2:1.18.4-2 is installed
> 
> Depends: xserver-xorg-core (>=
> 2:1.18.99.901) but 2:1.18.4-2 is installed
> The following actions will resolve these dependencies:
> 
>

Re: [qubes-users] Kali VM no longer responding

2016-12-12 Thread qubenix
Marek Marczykowski-Górecki:
> On Mon, Dec 12, 2016 at 05:10:00PM +0000, qubenix wrote:
>> Marek Marczykowski-Górecki:
>>> Looks like this issue:
>>> https://github.com/QubesOS/qubes-issues/issues/2514
>>>
>>> Rebuilt package just uploaded to testing repository
>>> (qubes-gui-agent_3.2.10-2+deb9u1).
>>>
>>>
> 
>> Doesn't seem to be fixed in stretch, stretch-testing, or
>> stretch-securitytesting yet.
> 
>> ```
>> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
>> dist-upgrade -y"
>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
>> Reading package lists...
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Calculating upgrade...
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> [user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-gui
>> ii qubes-gui-agent 3.2.8+deb9u1 amd64 Makes X11 windows available to
>> qubes dom0
>> ```
> 
> Interesting, I have qubes-gui-agent 3.2.11 already, from
> stretch-testing. Do you have some caching proxy in between?
> 
At one point I was using Rustybirds update cache proxy, but I've since
switched back to a whonix-gw and unchecked "Allow connections to Updates
Proxy".

I have two debian-9 templates, and they both were connected to update
cache and are now connected to whonix-gw. Here's the results from my two
debian-9 templates (one is using stretch-testing and
stretch-securitytesting the other has only stretch-testing although I
don't think that should matter):

```
[user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
dist-upgrade -y -V"
Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[user@dom0 ~]$ qvm-run -p d9-kali "sudo apt-get update && sudo apt-get
dist-upgrade -y -V"
Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
Hit:5 http://deb.bitmask.net/debian stretch InRelease
Hit:4 http://archive-3.kali.org/kali kali-rolling InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages have been kept back:
   qubes-gui-agent (3.2.8+deb9u1 => 3.2.11-1+deb9u1)
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
[user@dom0 ~]$ qvm-run -p d9-kali "sudo aptitude dist-upgrade"
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Building tag database...
The following NEW packages will be installed:
  xserver-xorg-input-qubes{ab} xserver-xorg-video-dummyqbs{ab}
The following packages will be upgraded:
  qubes-gui-agent
1 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 66.5 kB of archives. After unpacking 36.9 kB will be used.
The following packages have unmet dependencies:
 xserver-xorg-video-dummyqbs : Depends: xorg-video-abi-23 which is a
virtual package, provided by:
- xserver-xorg-core
(2:1.19.0-2), but 2:1.18.4-2 is installed

   Depends: xserver-xorg-core (>=
2:1.18.99.901) but 2:1.18.4-2 is installed
 xserver-xorg-input-qubes : Depends: xorg-input-abi-24 which is a
virtual package, provided by:
 - xserver-xorg-core (2:1.19.0-2),
but 2:1.18.4-2 is installed

Depends: xserver-xorg-core (>=
2:1.18.99.901) but 2:1.18.4-2 is installed
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) qubes-gui-agent [3.2.8+deb9u1 (now)]
2) xserver-xorg-input-qubes [Not Installed]
3) xserver-xorg-video-dummyqbs [Not Installed]



Accept this solution? [Y/n/q/?]
```

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/0e8cbae1-d606-6ff4-b65a-79417943bf4b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kali VM no longer responding

2016-12-12 Thread qubenix
Marek Marczykowski-Górecki:
> On Mon, Dec 12, 2016 at 12:17:16AM +, a.mcwh...@yandex.com wrote:
>> That means not only me has the same issue with debian-9 template. I've 
>> started reinstalling template.
> 
>> On December 12, 2016 11:01:00 AM AEDT, qubenix <qube...@riseup.net> wrote:
>>> Lucas Arnström:
>>>> Hi, I have been using a debian template converted into kali for quite
>>>> some time. But recently, neither the kali template nor any appvms
>>> based
>>>> on it are responding. I can start the vms just fine, but cant do much
>>>> other than that. It seems to be some recent change that induced this
>>>> problem, considering i have been able to use the very same vms for
>>> quite
>>>> some time. But after my last update they all stopped working.
>>>>
>>>> I have attempted to do a complete rebuild of my kali template. I got
>>>> everything set up, but as soon as I restarted the template I got the
>>>> same issue again.
>>>>
>>>> I'm attaching the logs.
>>>>
>>>> // Lucas
>>>>
>>>
>>> I've had this same experience after a dist-upgrade on my debian-9
>>> template (d9) about 12 hours ago. I had made a clone of this template
>>> about two weeks ago and added the kali repos and some packages.
>>> Strangely, my kali template (and AppVM based on it) work normal even
>>> though it was also upgraded at the same time.
>>>
>>> ```
>>> user@dom0:~$ qvm-run -p d9 gnome-terminal
>>> Unable to init server: Could not connect: Connection refused
>>> Failed to parse arguments: Cannot open display:
>>> ```
> 
> Looks like this issue:
> https://github.com/QubesOS/qubes-issues/issues/2514
> 
> Rebuilt package just uploaded to testing repository
> (qubes-gui-agent_3.2.10-2+deb9u1).
> 
> 

Doesn't seem to be fixed in stretch, stretch-testing, or
stretch-securitytesting yet.

```
[user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
dist-upgrade -y"
Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-gui
ii qubes-gui-agent 3.2.8+deb9u1 amd64 Makes X11 windows available to
qubes dom0
```
-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/c5b9c017-5864-abb5-529b-b995500ca705%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kali VM no longer responding

2016-12-12 Thread qubenix
Marek Marczykowski-Górecki:
> On Mon, Dec 12, 2016 at 12:17:16AM +, a.mcwh...@yandex.com wrote:
>> That means not only me has the same issue with debian-9 template. I've 
>> started reinstalling template.
> 
>> On December 12, 2016 11:01:00 AM AEDT, qubenix <qube...@riseup.net> wrote:
>>> Lucas Arnström:
>>>> Hi, I have been using a debian template converted into kali for quite
>>>> some time. But recently, neither the kali template nor any appvms
>>> based
>>>> on it are responding. I can start the vms just fine, but cant do much
>>>> other than that. It seems to be some recent change that induced this
>>>> problem, considering i have been able to use the very same vms for
>>> quite
>>>> some time. But after my last update they all stopped working.
>>>>
>>>> I have attempted to do a complete rebuild of my kali template. I got
>>>> everything set up, but as soon as I restarted the template I got the
>>>> same issue again.
>>>>
>>>> I'm attaching the logs.
>>>>
>>>> // Lucas
>>>>
>>>
>>> I've had this same experience after a dist-upgrade on my debian-9
>>> template (d9) about 12 hours ago. I had made a clone of this template
>>> about two weeks ago and added the kali repos and some packages.
>>> Strangely, my kali template (and AppVM based on it) work normal even
>>> though it was also upgraded at the same time.
>>>
>>> ```
>>> user@dom0:~$ qvm-run -p d9 gnome-terminal
>>> Unable to init server: Could not connect: Connection refused
>>> Failed to parse arguments: Cannot open display:
>>> ```
> 
> Looks like this issue:
> https://github.com/QubesOS/qubes-issues/issues/2514
> 
> Rebuilt package just uploaded to testing repository
> (qubes-gui-agent_3.2.10-2+deb9u1).
> 
> 

Doesn't seem to be fixed in stretch, stretch-testing, or
stretch-securitytesting yet.

```
[user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
dist-upgrade -y"
Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-guiii
qubes-gui-agent  3.2.8+deb9u1
amd64Makes X11 windows available to qubes dom0
```
-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/43f95f6f-3e98-a174-196c-d3799f1f565c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kali VM no longer responding

2016-12-11 Thread qubenix
Lucas Arnström:
> Hi, I have been using a debian template converted into kali for quite
> some time. But recently, neither the kali template nor any appvms based
> on it are responding. I can start the vms just fine, but cant do much
> other than that. It seems to be some recent change that induced this
> problem, considering i have been able to use the very same vms for quite
> some time. But after my last update they all stopped working.
> 
> I have attempted to do a complete rebuild of my kali template. I got
> everything set up, but as soon as I restarted the template I got the
> same issue again.
> 
> I'm attaching the logs.
> 
> // Lucas
> 

I've had this same experience after a dist-upgrade on my debian-9
template (d9) about 12 hours ago. I had made a clone of this template
about two weeks ago and added the kali repos and some packages.
Strangely, my kali template (and AppVM based on it) work normal even
though it was also upgraded at the same time.

```
user@dom0:~$ qvm-run -p d9 gnome-terminal
Unable to init server: Could not connect: Connection refused
Failed to parse arguments: Cannot open display:
```

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/7851f332-b97d-e5cb-3bb6-02d09be245da%40riseup.net.
For more options, visit https://groups.google.com/d/optout.