Re: [qubes-users] keyserver in template with saltstack unreachable

2021-12-04 Thread unman
On Sat, Dec 04, 2021 at 12:13:49PM +, lik...@gmx.de wrote:
> Hi,
> 
> I'm using in my saltstack formulas creating of repositories in a debian 
> template e.g.
> 
> add-repo:
>  pkgrepo.managed:
>   - name: deb http://repository.spotify.com stable non-free
>   - file: /etc/apt/sources.list.d/spotify-client.list
>   - humanname: spotify
>   - keyid: 5E3C45D7B312C643
>   - keyserver: keys.openpgpg.org
>   - gpgkey: https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg
>   - gpgcheck: 1
> 
> Unfortunately, I get this error after execution:
>     ID: add-repo
>   Function: pkgrepo.managed
>   Name: deb http://repository.spotify.com stable non-free
>     Result: False
>    Comment: Failed to configure repo 'deb [trusted=yes] 
> http://repository.spotify.com stable non-free': Error: key retrieval failed: 
> Executing: /tmp/apt-key-gpghome.xyY44SvGz1/gpg.1.sh --batch --keyserver 
> keys.openpgpg.org --logger-fd 1 --recv-keys 5E3C45D7B312C643
>     gpg: keyserver receive failed: Network is unreachable
> 
> Any ideas how to fix that? Is that connected that templates are using a proxy 
> for outbound connections which salt is not able to use for retrieving keys?
> Btw. none of the options works: keyid + keyserver nor gpgkey. I just added 
> both of the in the salt snipped.
> 
> Thanks! P.
> 

It is connected - you can find the solution online for using gpg behind
a proxy.
I have a note on this at http://github.com/unman/notes/ - that's a way
to get keys in to the template. Run that and keep the key retrieval out
of the salt state. Its workable.

-- 
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/YatyMDtmykpY9NoY%40thirdeyesecurity.org.


Re: [qubes-users] Qubes Update does not work for Whonix 16 templates ...

2021-11-07 Thread unman
On Sun, Nov 07, 2021 at 04:07:13AM -0800, Viktor Ransmayr wrote:
> I've installed Whonix 16 on my Qubes OS R4.0 system - and - have switched 
> 'sys-whonix' to 'whonix-gw-16' as well as 'anon-whonix' to 'whonix-ws-16'.
> 
> Everything seems to work fine - but - Qubes Updater reports that updates 
> are available for 'whonix-[gw | ws]-16' but always fails to update the 
> templates with error msgs similar to
> 
> ###
> 
> Updating whonix-gw-16
> 
> Error on updating whonix-gw-16: Command '['sudo', 'qubesctl', 
> '--skip-dom0', '--targets=whonix-gw-16', '--show-output', 'state.sls', 
> 'update.qubes-vm']' returned non-zero exit status 20
> whonix-gw-16:
>   --
> ID: update
>   Function: pkg.uptodate
> Result: False
>Comment: E: Release file for 
> tor+https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease 
> is not valid yet (invalid for another 14min 36s). Updates for this 
> repository will not be applied.
>Started: 11:15:16.396556
>   Duration: 8366.294 ms
>Changes:   
>   --
> ID: notify-updates
>   Function: cmd.run
>   Name: /usr/lib/qubes/upgrades-status-notify
> Result: False
>Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
>Started: 11:15:24.765086
>   Duration: 2514.791 ms
>Changes:   
> --
> pid:
> 1782
> retcode:
> 100
> stderr:
> stdout:
>   
>   Summary for whonix-gw-16
>   
>   Succeeded: 0 (changed=1)
>   Failed:2
>   
>   Total states run: 2
>   Total run time:  10.881 s
> 
> Updating whonix-ws-16
> 
> Error on updating whonix-ws-16: Command '['sudo', 'qubesctl', 
> '--skip-dom0', '--targets=whonix-ws-16', '--show-output', 'state.sls', 
> 'update.qubes-vm']' returned non-zero exit status 20
> whonix-ws-16:
>   --
> ID: update
>   Function: pkg.uptodate
> Result: False
>Comment: E: Release file for 
> tor+https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease 
> is not valid yet (invalid for another 16min 48s). Updates for this 
> repository will not be applied.
>Started: 11:13:10.907970
>   Duration: 2607.219 ms
>Changes:   
>   --
> ID: notify-updates
>   Function: cmd.run
>   Name: /usr/lib/qubes/upgrades-status-notify
> Result: False
>Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
>Started: 11:13:13.517469
>   Duration: 2907.295 ms
>Changes:   
> --
> pid:
> 1789
> retcode:
> 100
> stderr:
> stdout:
>   
>   Summary for whonix-ws-16
>   
>   Succeeded: 0 (changed=1)
>   Failed:2
>   
>   Total states run: 2
>   Total run time:   5.515 s
> 
> ###
> 
> What are the recommended steps to resolve this issue?
> 
> With kind regards,
> 
> Viktor
> 
> PS: I obviously tried this several time - but - the error msg stays the 
> same - only - with changing "invalid for ..." times ...
> 

Fix the time on your update qube,( and possibly your target). It is, as you can 
see, wrong.

-- 
I **never** presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

-- 
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/YYfkfi1uucy1jcWK%40thirdeyesecurity.org.


Re: [qubes-users] Re: best way to disable a linux service in a AppVM

2021-11-06 Thread unman
On Sat, Nov 06, 2021 at 04:34:02PM +, lik...@gmx.de wrote:
> On 11/6/21 16:23, badgateway wrote:
> > Is it an option to clone your current template and disable the services 
> > permanently in your new template?
> >
> 
> It is an option. But in this case I'd prefer the way using 
> /rw/config/rc.local not to maintain another template.
> 
> I've learned there must be 3 alternatives, otherwise you've not done enough 
> research. Maybe there's a 3rd way?
> 

There is indeed a third way, which fits nicely in to the Qubes
framework, and is used by qvm-service. Instead of disabling the
service, control it.

If your service is foo.service:
Create a folder foo.service.d, and create a file 10_qubes.conf with
something like
```
[Unit]
ConditionPathExists=/var/run/qubes/service/foo
After=qubes.sysinit.service
```

Now you can control with `qvm-service --enable  foo` in qubes
where you want the service to run.

You could invert the sense of control by using
ConditionPathExists=! but this may lead to confusion.

-- 
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/YYbELu4D%2Bcs250a9%40thirdeyesecurity.org.


Re: [qubes-users] Start disposable

2021-11-03 Thread unman
On Wed, Nov 03, 2021 at 05:29:33AM -0300, Franz wrote:
> On Wed, Nov 3, 2021 at 2:18 AM Andrew David Wong  wrote:
> 
> > On 11/2/21 6:14 PM, Franz wrote:
> > > Hello
> > > the documented way to start a disposable from dom0 is:
> > >
> > > $ qvm-run --dispvm= --service qubes.StartApp+firefox
> > >
> > >
> > > however this works well when the disposable template is based on Fedora,
> > > but when it is based on Debian it gives me the following error:
> > > disp6615: command failed with code: 1
> > > any idea?
> > >
> >
> > Is it possible that the command you're attempting to execute is not
> > being found in the disposable, e.g., because Firefox is not installed in
> > the template on which that disposable is (ultimately) based or because
> > the proper command to run it is different from `firefox`?
> >
> >
> Many thanks Andrew, it seems that somehow you are right, but in this sense
> strange things happen:
> 1. writing xterm or gnome-terminal rather than firefox results in "failed
> with code:1"
> 2. writing google-chrome rather than firefox correctly starts google-chrome
> and the generated disp2571 does not shutdown, so other tests are possible:
> 3. writing "qvm-run disp2571 firefox" correctly starts firefox
> 4. writing "qvm-run disp 2571 gnome-terminal" correctly starts
> gnome-terminal
> 
> So resuming why is it that this does not work:
> $ qvm-run --dispvm=deb-10-java-dvm --service qubes.StartApp+firefox
> but these work
> $ qvm-run --dispvm=deb-10-java-dvm --service qubes.StartApp+google-chrome
> $ qvm-run disp2571 firefox

The plain call to qvm-run attempts to run the executable directly.
This is why `qvm-run disp2571 firefox` works.

The use of `--service qubes.StartApp+` tries to start an application
using a *desktop file* - in Debian, the file for the firefox
application is called firefox-esr - it's at
/usr/share/applications/firefox-esr.desktop

So with that usage you need:
`qvm-run --dispvm=deb-10-java-dvm --service qubes.StartApp+firefox-esr`

xterm does not have a desktop file - so you cant use the  
`--service qubes.StartApp+` approach at all unless you provide one.

-- 
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/YYKbKmWJ2oeo45uu%40thirdeyesecurity.org.


Re: [qubes-users] Re: usb keyboard not working on debian 11 template

2021-10-14 Thread unman
On Wed, Oct 13, 2021 at 06:38:19PM +0200, haaber wrote:
> > Unman wrote:
> > qubes-input-proxy-sender is installed by default in the debian-11
> > template.
> > If you are using a minimal template, this is meant for advanced users,
> > but in any case, installation of qubes-input-proxy-sender is documented
> > at https://www.qubes-os.org/doc/templates/minimal/
> > 
> 
> Dear unman, do you suggest rather upgrading a debian-10-minimal to
> debian-11-minimal, or re-installing a fresh one? In the 2nd case, what
> is the preferred install command in dom0? I am a bit confused, since
> there is good old qubes-dom0-update, there is salt, maybe another one.
> Which is best/safest?   Cheers, Bernhard

Personally I will (usually) install a fresh template - there isnt as yet
a stable Debian-11 template for Qubes though.
I (usually) do this from salt, but there is the handy qvm-template
command in 4.1.

-- 
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/YWhIloVirY9939Fs%40thirdeyesecurity.org.


Re: [qubes-users] Qubes 4.1 - ready to go on Nitropad X230 without much tweaks?

2021-10-13 Thread unman
On Wed, Oct 13, 2021 at 10:24:46AM +, 'taran1s' via qubes-users wrote:
> I am thinking about upgrading my Nitropad X230 Qubes to 4.1, but I am
> curious if the version 4.1 has some serious issues that would make the
> experience worse than the current 4.0 or would need many tweaks to make the
> beast run well.
> 
> I know that the 4.1 is an rc1 with all its pros and cons, which can be but
> different on each hardware. My question is if the Nitropad X230 has some
> functionality issues running the 4.1-rc1 now.
> 
> For sys-net and sys-firewall I use the fedora-33-minimal, I use
> qubes-gpg-split and a kind of split monero with qrexec, as described here: 
> http://monerotoruzizulg5ttgat2emf4d6fbmiea25detrmmy7erypseyteyd.onion/resources/user-guides/cli_wallet_daemon_isolation_qubes_whonix.html,
> sys-usb is based on debian-10. The rest is a normal usage with not so many
> changes in the dom0 or templates from the default state.
> 
> Would you recommend to go on with the upgrade/reinstall of my 4.0 Qubes to
> 4.1 on Nitropad X230 now?
> 
> Thank you.
> 
> -- 
> Kind regards
> taran1s

4.1rc1 works fine on a corebooted x230 (that's what the nitropad is).
No functionality issues for me, and I cant see any issues with your set
up.
You'll have to reseal HEADS of course, but I assume you know that.

-- 
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/YWbzmAoqBBMNQmbz%40thirdeyesecurity.org.


Re: [qubes-users] Unable to install templates in Qubes OS 4.1beta

2021-10-11 Thread unman
On Mon, Oct 11, 2021 at 09:55:47PM +0200, 799 wrote:
> Hello,
> 
> I have setup Qubes 4.1 on my Surface and now I am running into issues
> trying to install more templates.
> sys-net is set as Dom0 Update VM and I am also able to search for packages
> and they get listed correctly.
> 
> [user@dom0 ~]$ sudo qubes-dom0-update --action=search qubes-template-
> Using sys-net as UpdateVM to download updates for Dom0; this may take some
> time...
> 
> Strangely the output (listed packages) is not shown in dom0 but in the
> sys-net in a windows with sh as shell.
> The first line says: Converting database from bdb_ro to sqlite backend
> Then I get a list of the templates.
> 
> ... but if I try install via:
> [user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-33
> 
> ... I can see that it will download the package but I get:
> 
> Using sys-net as UpdateVM to download updates for Dom0; this may take some
> time...
> Last metadata expiration check: -1 day, 21:47:12 ago on Mon 11 Oct 2021
> 05:49:33 PM CEST.
> No match for argument: qubes-template-fedora-33
> Error: Unable to find a match: qubes-template-fedora-33
> 
> Any idea where I can look for the root cause as I am a bit desparate.
> 
> One7two99
> 

The output appearing in sys-net is a new security feature in 4.1.
The "converting database" line is to be expected (but annoying on each
run with a disposable)

I'm not sure why you see "Unable to find a match".
The obvious reason would be that you already have a fedora-33 template
installed.

What do you mean by - "I can see that it will download the package"?

-- 
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/YWRRx6SFupkR6cIB%40thirdeyesecurity.org.


Re: [qubes-users] Re: usb keyboard not working on debian 11 template

2021-10-08 Thread unman
On Wed, Oct 06, 2021 at 10:48:14PM +0200, 'qtpie' via qubes-users wrote:
> Installing qubes-input-proxy-sender in the template it was. Problem solved.
> Thanks awokd!
> 
> Note: to avoid this problem, these should either be default installed
> packages in all templates, or be documented in
> https://www.qubes-os.org/doc/usb-qubes/. If the latter is preferred, I can
> adapt the documentation. Please let me know.
> 

qubes-input-proxy-sender is installed by default in the debian-11
template.
If you are using a minimal template, this is meant for advanced users,
but in any case, installation of qubes-input-proxy-sender is documented
at https://www.qubes-os.org/doc/templates/minimal/

-- 
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/YWArvIPQtqpjNn4I%40thirdeyesecurity.org.


Re: [qubes-users] Debian 10 - Update Errors

2021-10-04 Thread unman
On Fri, Oct 01, 2021 at 07:20:16AM -0700, load...@gmail.com wrote:
> *$ sudo apt-get update*
> Get:1 http://ftp.debian.org/debian buster-backports InRelease [46.7 kB]
> Hit:2 https://contrib.qubes-os.org/deb/r4.0/vm buster InRelease
> 
> Hit:3 https://deb.qubes-os.org/r4.0/vm buster InRelease
> 
> Hit:4 https://deb.debian.org/debian buster InRelease   
> Get:5 https://deb.debian.org/debian-security buster/updates InRelease [65.4 
> kB]
> Err:2 https://contrib.qubes-os.org/deb/r4.0/vm buster InRelease
>   The following signatures were invalid: EXPKEYSIG A8F7A1DC99F29DAA Qubes 
> OS Contrib Release 4 Signing Key
> Fetched 112 kB in 1s (134 kB/s) 
> Reading package lists... Done
> *W: An error occurred during the signature verification. The repository is 
> not updated and the previous index files will be used. GPG error: 
> *https://contrib.qubes-os.org/deb/r4.0/vm 
> buster* InRelease: The following signatures were invalid: EXPKEYSIG 
> A8F7A1DC99F29DAA Qubes OS Contrib Release 4 Signing Key*
> *W: Failed to fetch *
> https://contrib.qubes-os.org/deb/r4.0/vm/dists/buster/InRelease*  The 
> following signatures were invalid: EXPKEYSIG A8F7A1DC99F29DAA Qubes OS 
> Contrib Release 4 Signing Key*
> *W: Some index files failed to download. They have been ignored, or old 
> ones used instead.*
> 
> 
> Does anybody has the same problem with updating of the Debian 10 version?
> 
As you can see the key for the "Contrib" repository was out of date.
It's a known issue, and a fix is provided in an update package on its
way.

-- 
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/YVrzZKsA6Pq5dQg2%40thirdeyesecurity.org.


[qubes-users] New Prebuilt templates - Arch, Ubuntu and Mint, for 4.0 and 4.1

2021-09-28 Thread unman
Hi

I've recently uploaded some new pre-built templates for 4.0, and 4.1
An updated Arch Linux, Ubuntu Focal, and a new Mint (uma).

All my templates, packages and repositories, are signed with
my Qubes Signing key - you can get this from any key server. You
should check this against other sources - https://qubes.3isec.org,
here on the list, https://github.com/unman/unman
maybe another key server over Tor.

You should do something like this, in a Fedora disposable - make sure
you have enough space in the qube you use to download.
Download the template you want from https://qubes.3isec.org/

Once you have downloaded and confirmed my "Qubes OS signing key", add it to
your rpm keyring:
`sudo rpm --import `

Check the signature on the template:
`rpm -K `
If all is well you will see "digests signatures OK"

Once you are satisfied, install the Template.
To do this you will need to copy it to dom0.
In dom0, run:
`qvm-run -p   'cat ' > 
`

Then, in dom0, install:
`sudo dnf install `

For example, if you have downloaded an Arch template in a qube called
`downloader`, and the file is in `/home/user/Downloads`:
`qvm-run -p  downloader 'cat 
/home/user/Downloads/qubes-template-archlinux-4.0.6-202109222348.noarch.rpm ' > 
arch.rpm`
(You can name the package whatever you like in dom0.)

Then install with: `sudo dnf install arch.rpm`

I also provide repositories for Qubes packages for Arch and Ubuntu,
which are (fairly) regularly updated.  Details at https://qubes.3isec.org

If you need help, have issues, or find any problems, answer here.

unman

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


Re: [qubes-users] Networking issue after upgrading to Fedora-33

2021-09-28 Thread unman
On Mon, Sep 27, 2021 at 06:36:16AM -0700, mgla...@gmail.com wrote:
> 
> Yes, there are custom firewall rules, but the firewall is set to  "Allow 
> all outgoing internet connections". Which should ignore all the rules?
> 

AFAIK, if you set custom firewall rules, they override the GUI firewall
setting.
Inspect the rules applying on sys-firewall.

-- 
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/YVL5gULN%2BHFpdhCt%40thirdeyesecurity.org.


Re: [qubes-users] Networking issue after upgrading to Fedora-33

2021-09-27 Thread unman
On Mon, Sep 27, 2021 at 02:35:34AM -0700, mgla...@gmail.com wrote:
> 
> Hi everyone,
> 
> I'm looking for some help as to how to diagnose some app-VM networking 
> issues. I have 2 vms, both based on the same template with identical 
> config, but one can reach the internet and the other cannot.
> 
> Before upgrading:
> 2 standalone VMs based on Fedora-30. One with a bunch of dev tools 
> installed, one relatively untouched. I had multiple VMs based on these two 
> templates. I also updated my sys-net and sys-firewall to Fedora-33 at the 
> same time.
> 
> Upgrade:
> I upgraded to Fedora-33, and realised I could rationalise my VMs, so now 
> every appVM is based off the same Fedora-33 template.
> 
> The issue:
> Some of my migrated VMs are completely fine, others have no network. 
> I _think_ it is the VMs that used to be based on my old "untouched" vm that 
> have the issue. 
> 
> VM1:
> No networking at all.
> 
> VM2:
> Networking is completely fine, everything works as expected.
> 
> Both VMs are based on the same Fedora-33 template, with the same (default) 
> sys-firewall Networking, both with the firewall configured to allow all 
> outgoing internet connections
> 
> *vm1$ ping google.com*
> ping: google.com: Name or service not known
> 
> *vm1$ dig google.com*
> ; <<>> DiG 9.11.35-RedHat-9.11.35-1.fc33 <<>> google.com
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> 
> *vm1$ resolvectl dns*
> Global: 10.139.1.1 10.139.1.2
> Link 2 (eth0):
> 
> 
> *vm2$ resolvectl dns*
> Global: 10.139.1.1 10.139.1.2
> Link 2 (eth0):
> Link 3 (br-11bfb2cd10e9):
> Link 4 (docker0):
> Link 5 (br-cf58034d074b):
> Link 6 (br-f9686c41a7f5):
> 
> So there's definitely something wrong, but I don't know enough about 
> Linux/Qubes networking to work out what.
> 
> Any pointers gratefully received.
> 

There is something wrong, but there is nothing in the detail you have
provided that might explain it.
So:
Do you have any custom firewall rules set on vm1? (qvm-firewall vm1)
Can you ping the firewall from vm1, by IP address?
Can you access a host on the internet by IP address?(e.g https://9.9.9.9)
If you create a new qube from the template, does networking work as
expected?
If you change templates on vm1, does networking work?

-- 
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/YVHABAtgLCNk14le%40thirdeyesecurity.org.


Re: [qubes-users] how to modify qubes-installer-ISO

2021-09-24 Thread unman
On Fri, Sep 24, 2021 at 09:07:38AM +0200, haaber wrote:
> 
> > > > I would like to modify the qubes-iso (add a different kernel, maybe add
> > > > a wireless driver). Did someone here solve that already? A brief google
> > > > on the subject reveals that modifying ISO's is not straightforward ...
> > > > and touching the kernel may add extra difficulties.
> > > 
> > > https://www.qubes-os.org/doc/qubes-iso-building/ covers building the iso.
> > > Adding a different kernel would be difficult, but I think you could stage
> > > the wireless driver in one of the template builds it contains.
> > > 
> > 
> > It is relatively easy to build a custom iso, and certainly to include
> > alternate kernel builds and drivers in the templates. (I assume that
> > this is what you want.)
> > If you use the stock templates, then you can customise them simply
> > enough by adjusting the build parameters, and packages, in (e.g.) 
> > builder-debian.
> > 
> 
> Thank you, awokd and unman. So I cannot just take the std installer,
> unpack the iso, add/replace a kernel, and repack it? That is certainly a
> bit naïve as approach, but since I can do the same with a working
> xen/qubes why is the installer so different?  Bernhard
> 

>From your post I thought you wanted to include material in the
templates, as I said..
If all you want to do is change a dom0 parameter, or package, then you
can do what you say - unpack, change, repack. (People do this for UEFI
parameters, I think.)
You wont be able to distribute that iso unless you rework the check, but
it should be fine for your purposes.

-- 
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/YU268aMlouaR66t/%40thirdeyesecurity.org.


Re: [qubes-users] how to modify qubes-installer-ISO

2021-09-20 Thread unman
On Sun, Sep 19, 2021 at 07:51:02PM +, 'awokd' via qubes-users wrote:
> Bernhard:
> > Dear qubes-community,
> > 
> > I would like to modify the qubes-iso (add a different kernel, maybe add
> > a wireless driver). Did someone here solve that already? A brief google
> > on the subject reveals that modifying ISO's is not straightforward ...
> > and touching the kernel may add extra difficulties.
> 
> https://www.qubes-os.org/doc/qubes-iso-building/ covers building the iso.
> Adding a different kernel would be difficult, but I think you could stage
> the wireless driver in one of the template builds it contains.
> 

It is relatively easy to build a custom iso, and certainly to include
alternate kernel builds and drivers in the templates. (I assume that
this is what you want.)
If you use the stock templates, then you can customise them simply
enough by adjusting the build parameters, and packages, in (e.g.) 
builder-debian.

-- 
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/YUiKzw/GxVXwheK/%40thirdeyesecurity.org.


Re: [qubes-users] error when pasting from global clipboard

2021-09-12 Thread unman
On Sun, Sep 12, 2021 at 02:35:25PM +0300, Mustafa Kuscu wrote:
> Hi,
> 
> I have recently updated my system which apparently broke global clipboard
> functionality.
> 
> After reading the docs, I have checked the log file at
> /var/log/qubes/guid.domain_id.log which adds this line whenever ctrl +
> shift + v is being pressed:
> 
> connect: No such file or directory
> 
> I have repeated with debug mode enabled on the vm, however no extra
> information was added to that file.
> 
> The issue first emerged when I installed a few packages from testing
> repository. But still want to debug this further, any ideas on where to
> look at?
> 
> Kind Regards,
> -- 
> 
> Mustafa
> 

What was your update?
What were the packages you installed?
Does this affect all qubes, or specific to some, or a particular
template?
Do you see the popup when you use Ctrl+Shift+C?

-- 
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/YT3ptuPNLq5UPqOF%40thirdeyesecurity.org.


Re: [qubes-users] qvm-usb is broken in qubes 4 / debian-10

2021-09-09 Thread unman
On Wed, Sep 08, 2021 at 09:00:17PM +0400, Vitali Andrusevich wrote:
> Small update:
> 
> Upgraded Debian Template From Debian-10 to Debian-11.
> It didn't help unfortunately. Problem persists.
> 
> BTW, USB attachment to VM running Fedora-32 Template still works without any
> problems.
> 
> Regards,
> Vit

You don't say if you are using 4.0 or 4.1
I don't see this behaviour in either.
Can you test with a vanilla template (either 10 or 11)? Have you made
any modifications to that template?

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


Re: [qubes-users] building cubes how to include custom patches

2021-09-09 Thread unman
On Thu, Sep 02, 2021 at 08:46:38PM +, 'awokd' via qubes-users wrote:
> ludwig...@gmail.com:
> > Hi all,
> > I would like to patch some sources of xen and would like to know how
> > to introduce the patches into the build system.
> 
> There is a patch directory somewhere in the build environment where custom
> Qubes patches get applied to the Xen kernel. It may be inside the chroot
> filesystem, but I don't have a build VM handy to confirm. Run something like
> "sudo find -name *patch*" at the top level of your build machine and I think
> you can find it, then check the make file that applies the patches to add
> your own.

Put with the other patches in vmm-xen, and adjust xen.spec.in

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


Re: [qubes-users] qubes packages in Archlinux AUR repo

2021-08-30 Thread unman
On Tue, Aug 31, 2021 at 07:38:33AM +0800, rss+qu...@armor-mail.com wrote:
> Hi unman,
> 
> > I cant help with the AUR.
> > I build Arch packages for 4.0 and 4.1, and update them probably twice
> > a month ( other constraints permitting)
> 
> Thanks very much for doing that, my Arch template originally came from
> your repo.
> 
> > You can pick up templates and packages at https://qubes.3isec.org
> > unman
> 
> I imported your package signing key with pacman-key ("pacman-key
> --finger unman" finds the key just fine) but if I try to do an upgrade
> (pacman -Syu) I get (transcribed so there may be typos):
> 
>   error: qubes-r4.0: signature from "unman (Qubes OS Signing Key)
>   " is invalid
> 
> Any thoughts? (I think I hit this iceberg before, and that is why I
> have been using the AUR packages.)
> 

I've just confirmed that this works fine for me.
Can you try downloading the key from the Ubuntu keyserver, and checking against
the details at my GitHub account?

"Signature is invalid" - strange error. Is your date/time correct?

-- 
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/20210831014419.GB22652%40thirdeyesecurity.org.


Re: [qubes-users] qubes packages in Archlinux AUR repo

2021-08-28 Thread unman
On Sat, Aug 28, 2021 at 03:59:01PM +0800, rss+qu...@armor-mail.com wrote:
> Hi,
> 
> Wondering if the Archlinux dev "seberm" is on this list, and what (if
> anything) is happening with the Qubes AUR packages? 
> 
>   https://aur.archlinux.org/packages/?O=0=qubes
> 
> I have been using these repos (the six of them that are not "empty")
> to keep my Arch AppVM alive for quite some time now (years?) and for
> the first time in a very long time, I seem to have a hard failure. The
> Arch VM boots, but X does not work.
> 
> (Basically, if no one is working this I need to move on from Arch)
> 
> TIA.
> 

I cant help with the AUR.
I build Arch packages for 4.0 and 4.1, and update them probably twice a
month ( other constraints permitting)
You can pick up templates and packages at https://qubes.3isec.org
unman

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


Re: [qubes-users] Salting your Qubes

2021-08-20 Thread unman
On Wed, Aug 18, 2021 at 03:36:10AM +0200, Trust me I am a Doctor wrote:
> 
> unman  writes:
> 
> >> Because whonix ensure updates comes from the tor network. I didn't
> >> figured yet if it is desirable to search to do something here.
> >>
> >
> > I dont use Whonix.
> > Since you can configure cacher to fetch across the Tor network, this
> > looks brain dead to me. I think you must mean that Whonix ensures that
> > updates run through Whonix.
> 
> Yes. That's it.
> 
> In another thread you spoke about not indexing for each template (so
> eventually reducing our fingerprint by reducing the request we made,
> right?) ; and potential drawbacks, do you mind to share what you find
> about that?  I know there is this this checkbox in acng-report.html but
> don't know what option exactly it correspond in acng.conf nor the
> drawbacks and eventual mitigations.
> 

The checkbox there is only used in admin operations.

You could look at FreshIndexMaxAge - this is used to "freeze" the index
files if clients are updating at nearly the same time.
In Qubes, this happens a lot.
Set that to a large value, and you can restrict the repeated calls to
fetch the indexes.
This is good - it means that (e.g.) there would be only 1 call to fetch
the Debian indexes while updating 15 templates.
This may be bad - if new packages are released during the "freeze", the
clients will only have the old versions in index and cache. They could
miss crucial security updates.
As always, it's a trade off.


-- 
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/20210820151755.GC6081%40thirdeyesecurity.org.


Re: [qubes-users] Help with qrexec [#usb #StandaloneVMs #external_devices]

2021-08-17 Thread unman
On Thu, Aug 05, 2021 at 07:42:49AM +0200, 'Ing Gianluca Cavallo' via 
qubes-users wrote:
> I'm a completely newbie qubes os user and I have this issue to solve and 
> maybe for you is too simple because you know what qubes is.
> I created a StandaloneVM that means that it doesn't communicate with other 
> VMs and it souds great.
> But I need, temporary, to relax this option and I see that there is a deamon 
> called qrexec that is responsable of this channel, so if I get what it is, I 
> should need the command to give in dom0 to open and close the devices 
> communication ports with the VMs.
> In my case I created both a linux and a windows standaloneVM but I need to 
> connect a digitalsign USB device because its driver is only for windows. For 
> linux I have other needs.
> Could you tell me how I can open this channel ? so how I can make the usb 
> available for the standaloneVM ?
> Is it possibile to execute a standaloneVM as root ?
> Thanks in advance
> Ing
> 


If I understand you, you want to be able to connect a USB device to the
standalones.
You *could* attach the USB controller to the standalone using the
"Devices" tab on the qubes Settings. I suspect that this isn't what you
want, and that what you want to do is keep the device attached to
sys-usb and pass it through to the standalone. 
For Windows, there are Qubes Windows Tools, which provide *some* qrexec
functions, like inter-qube copy and paste. Unfortunately I don't believe
that the tools currently support USB pass through. So the only option
would be to attach the USB controller. (I'm not a Windows user.)
For Linux, this would depend on what distribution you have used for the
standalone. You haven't said. If it is one of the stock qubes distros
then you *may* be able to install qubes packages and have them work -
note that "may". The best bet would be to create a standalone from an
existing template.

I don't understand your question about executing a standalone as root. If
you mean "can I run as root in the standalone" the answer is "Of course"
- how you get to do this depends on what distribution of Linux you are
using.




-- 
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/20210817155339.GB15065%40thirdeyesecurity.org.


Re: [qubes-users] dependencies of qubes-gpg-split in debian minimal templates

2021-08-16 Thread unman
On Sun, Aug 15, 2021 at 10:24:39PM +0200, Trust me I am a Doctor wrote:
> 
> Hi,
> 
> Processing to set up again qubes-gpg-split in my vms, qubes v4.0, I
> assume I have to install the package qubes-gpg-split to have the command
> qubes-gpg-client in the client and server VM.
> 
> My client template is up to date and upgraded before asking the package.
> 
> However looking at the dependencies involved I just don't understand,
> starting with a set of dictionary packages, and then a lot of other
> stuff. Some make sense, I didn't check all. But dictionnaries ? Intel
> drivers ? What's the matter for setting up this split gpg client ?
> 
> Please look at this output of apt :
> 


> 
> Is something bad with my template or is this normal behavior ?

It's all fine.

If you check the dependencies of the package, you'll see:
gnupg2
libc6
zenity

A moments thought, and 2 moments checking, will tell you that most of the
packages are pulled in by zenity.

Debian provides apt-rdepends which will show you the dependency tree for
a package - useful in this sort of case.

-- 
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/20210816124906.GG5111%40thirdeyesecurity.org.


Re: [qubes-users] Salting your Qubes

2021-08-06 Thread unman
On Wed, Jul 28, 2021 at 10:18:45PM +0200, Trust me I am a Doctor wrote:
> 
> unman  writes:
> 
> > The repository was unavailable for a while. Was that the issue?
> 
> Yes. I panicked.
> 
> > Yes, apt-cacher-ng  works for Fedora updates.
> 
> Thanks for the details. I finally took the time to look at it.
> 
> > You have to make some changes -
> > First, on the client side, comment out "metalink" lines, and uncomment
> > "baseurl" lines.
> 
> The cisco repository of the codec openh264 does not have a baseurl, I
> found that I could use
> http://HTTPS///codecs.fedoraproject.org/openh264/$releasever/$basearch
> in place, I assume this can be safely added to
> /etc/apt-cacher-ng/fedora_mirrors
> 
> Also fedora ships with
> #baseurl=https://download.example/[...]
> in /etc/yum.repos.d conf files, I assume I had to replace them with
> baseurl=http://HTTPS///downloads.fedoraproject.org/[...]
> 
> 
> Then don't forget to
> $ dnf clean all
> 
> > This is because the metalink will keep loading new https://
> > repositories, and apt-cacher-ng cant cache those requests, as you
> > know.
> 
> I think we could also specify =http on metalinks as explained in
> https://unix.stackexchange.com/questions/240010/how-to-create-an-on-demand-rpm-mirror/426331#426331
> I have not tested it thought.

I have seen that, but generally I dont want clear traffic, so its not a
good option for me.

> 
> > Second, watch the caches in /var/cache/apt-cacher-ng , and add
> > any new ones to the fedora_mirrors file - this is because that file
> > doesn't contain all Fedora repositories.
> 
> It is maybe too soon to see, I don't know yet if having manipulated the
> url to use downloads.fedoraproject.org will effectively lead to mirrors
> to manage. What I know is, it was creating a directory named
>   downloads.fedoraproject.org
> before I add
>   https://downloads.fedoraproject.org/pub/fedora/linux/
> to
>   /etc/apt-cacher-ng/fedora_mirrors
> 
> And that downloads.fedoraproject.org is supposed to redirect to mirrors...
> 
> In the doubt I run a script to duplicate all http url of fedora_mirror
> to https.
> 
> 
> 
> I put a systemd timer to watch new directories on /var/cache/apt-cacher-ng/
> 
> I also put a timer to run /etc/cron.daily/apt-cacher-ng that manage
> expired files and make the html report.
> 
> Interestingly enough debian ships with scripts in
> /usr/share/doc/apt-cacher-ng/examples/dbgenerators.gz
> that may take care to update the mirrors files list at the cost of a
> lengthy cycle of queries ... That could be triggered weekly.
> 
> Do you known about it?
> 

Yes, but I've never(?) used it - the default lists are pretty good, and
it takes nothing to check if there are any rogue mirrors being fetched.

> Your instruction didn't said anything for the AppvM so I figured out
> that I could put an instruction in /rw/config/rc.local to switch back
> the repositories files to their initial values so I can still test out
> packages there before really installing them in a template.
> 
> 
> 
> Lastly, whonix-* will fail to update with, in 
> dom0:/etc/qubes-rpc/policy/qubes.UpdatesProxy
> 
> $type:TemplateVM $default allow,target=cacher
> 
> Because whonix ensure updates comes from the tor network. I didn't
> figured yet if it is desirable to search to do something here.
> 

I dont use Whonix.
Since you can configure cacher to fetch across the Tor network, this
looks brain dead to me. I think you must mean that Whonix ensures that
updates run through Whonix.

-- 
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/20210806140841.GC754%40thirdeyesecurity.org.


Re: [qubes-users] Re: Safely set up a Qube to connect to only one IP address on the Internet

2021-07-30 Thread unman
On Mon, Jul 26, 2021 at 08:09:52AM +, Michael Singer wrote:
> On Thu, Jul 17, 2021 at 12:29PM +0700, unman wrote> On Thu, Jul 15, 2021 at 
> 06:07:59PM +, Michael Singer wrote:
> >> On Thu, Jul 15, 2021 at 04:50:29PM +0700, unman wrote:
> >>
> >>> On Wed, Jul 14, 2021 at 04:35:42PM +, Michael Singer wrote:
> >>
> >>>>
> >>>> Would you let my Qube, which is supposed to connect to only one IP 
> >>>> address on
> >>>> the internet, be based on an extra firewall-vm? Would that more secure?
> >>
> >>> You could do this: it would have one particular advantage, in that you
> >>> could set custom rules in sys-net to restrict access from that
> >>> sys-firewall to the specified IP address.
> >>
> >> Do you have an example of the command line commands you use to set such 
> >> custom rules in an ordinary debian or fedora sys-net?
> > 
> > Qubes uses NAT, so sys-net sees all traffic coming from the IP address
> > of sys-firewall.
> > If you new fw has IP - 10.137.0.200
> > And target is 195.10.223.181
> > 
> > `nft insert rule filter FORWARD index 1 ip saddr  10.137.0.200 ip daddr 
> > 195.10.223.181 tcp dport https accept`
> > `nft insert rule filter FORWARD index 2 ip saddr  10.137.0.200 drop`
> > 
> > Would do it.
> > Adjust for your case, of course
> 
> Many thanks, unman! This is well explained. Allow one more question: How 
> would you do the same if sys-net is based on a OpenBSD template?
> 
> Best regards
> Michael Singer
> 

openBSD in Qubes - Excellent!
You would want something like:
pass out on dc0 proto tcp from 10.137.0.200 to 195.10.223.181 port 443

-- 
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/20210730134003.GF19478%40thirdeyesecurity.org.


Re: [qubes-users] Re: How to join the new Qubes OS testing team (message from deeplow & unman)

2021-07-30 Thread unman
On Thu, Jul 29, 2021 at 11:10:54PM -0700, Andrew David Wong wrote:
> On 7/29/21 9:05 AM, Yethal wrote:
> > Does running automated tests on own hardware count as being part of testing
> > team? I have some spare machines I can dedicate to that
> > 
> 
> Thanks! That's a good question. I'm not entirely certain. It might be best
> to ask this in the testing section of the forum.
> 

Thanks- it probably would, and could play an important part.
One of the problems with Qubes is that we know the packages compile and
pass some tests. What's missing is the use testing, and that's primarily
what the testing team is aimed at. Automated tests can certainly play
some part in that.

-- 
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/20210730101336.GB18732%40thirdeyesecurity.org.


Re: [qubes-users] Firewall Question - accessing LAN when appvm is using vpnVM?

2021-07-21 Thread unman
On Wed, Jul 21, 2021 at 12:28:22PM +, Stumpy wrote:
> I prefer to us a vpn proxy when possible so most of my appvms are setup to
> use a vpn proxy vm. The problem is a few of my appvms need access to my home
> server on my LAN but so far I cant seem to figure out how to access my
> server on an appvm when it is connected to a vpnvm.
> 
> Somehow this seems like a "firewall thing" but am not sure how to go about
> fixing it, would I make an exception (somehow?) for my local server in the
> vpnvm firewall or make another proxy vm that first allows that access and
> otherwise sends traffic on to the vpnvm?
> 

Yes, you would need to adjust the firewall, so that traffic from that
qube destined for the local network didn't get sent to the VPN. You'd
need to do this on the vpnvm directly.

I think a better route would be to have another qube connected to
sys-firewall, with access to the local network (only), and then sync
files as you wish to the VPN connected qubes.

-- 
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/20210721140206.GD27573%40thirdeyesecurity.org.


Re: [qubes-users] Debian onion repo v2 deprecation - any debian v3 onions alternatives

2021-07-20 Thread unman
On Mon, Jul 19, 2021 at 05:48:40AM -0700, lama...@gmail.com wrote:
> Not sure how to get the sources.list automatically updated with the new v3 
> onions. 
> You can copy+paste them manually, for a guide look here:
> https://www.whonix.org/wiki/Onionizing_Repositories
> 
> I didn´t even have apt-transport-tor installed in debian templates, but 
> installing it does not add the v3 onions.
> 
> On Tuesday, July 6, 2021 at 4:18:24 PM UTC+2 taran1s wrote:
> 
> >
> >
> > unman:
> > > On Tue, Jul 06, 2021 at 10:00:23AM +, 'taran1s' via qubes-users 
> > wrote:
> > >> I have my debian based templates updating repos onionized through 
> > existing
> > >> v2 onions. Tor Project announced that it will deprecate the v2 onions. 
> > Are
> > >> there any alternative debian v3 onions for debian updates?
> > >>
> > > 
> > > The Qubes onion repos are v3.
> > > If you have updated apt-transport-tor, then you should already be using
> > > v3 onions.
> >
> > I onionized the debian and whonix templates long time ago. In my 
> > /etc/apt/sources.list and etc/apt/sources.list.d/qubes-r4.list in debian 
> > I can still see v2 onions only:
> >
> > deb http://vwakviie2ienjx6t.onion/debian buster main contrib non-free
> > deb http://sgvtcaew4bxjd7ln.onion buster/updates main contrib non-free
> >
> > Should I run sudo apt update apt-transport-tor in each debian-based 
> > template to include the v3 onions?
> >
> >
> > -- 
> > Kind regards
> > taran1s
> >
> > gpg: 12DDA1FE5FB39C110F3D1FD5A664B90BD3BE59B3
> >

Updating the package does not automatically update the lists.
I meant that by updating, the REAME tells you v3 addresses to use. (At
least for bullseye, and probably backports, but I haven't checked.)
You always need to make these changes manually, I think.

-- 
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/20210720120509.GC20055%40thirdeyesecurity.org.


Re: [qubes-users] Re: Safely set up a Qube to connect to only one IP address on the Internet

2021-07-17 Thread unman
On Thu, Jul 15, 2021 at 06:07:59PM +, Michael Singer wrote:
> On Thu, Jul 15, 2021 at 04:50:29PM +0700, unman wrote:
> 
> > On Wed, Jul 14, 2021 at 04:35:42PM +, Michael Singer wrote:
> 
> >> 
> >> Would you let my Qube, which is supposed to connect to only one IP address 
> >> on
> >> the internet, be based on an extra firewall-vm? Would that more secure?
> 
> > You could do this: it would have one particular advantage, in that you
> > could set custom rules in sys-net to restrict access from that
> > sys-firewall to the specified IP address.
> 
> Do you have an example of the command line commands you use to set such 
> custom rules in an ordinary debian or fedora sys-net?

Qubes uses NAT, so sys-net sees all traffic coming from the IP address
of sys-firewall.
If you new fw has IP - 10.137.0.200
And target is 195.10.223.181

`nft insert rule filter FORWARD index 1 ip saddr  10.137.0.200 ip daddr 
195.10.223.181 tcp dport https accept`
`nft insert rule filter FORWARD index 2 ip saddr  10.137.0.200 drop`

Would do it.
Adjust for your case, of course

> 
> >> In the Qube settings for the services there is the service
> >> "disable-default-route". I have not found anything about what it does. In 
> >> my
> >> case, would it be better to leave it on or turn it off?
> 
> > man qvm-service - this service will remove the default gateway entry. So
> > a qube would be able to access immediate neighbours but not step beyond.
> > It's not what you want here.
> 
> What are the immediate neighbors of a qube?

Qubes that are connected - the netvm, or a qube for which *this* is the
netvm.

> 
> Can both a qube using the default route and a qube with the 
> disable-default-route service turned on access its immediate neighbors, or 
> only a qube with the disable-default-route service turned on?

You can always access immediate neighbours, but will have to adjust the
default firewall rules.
Look at
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes

> 
> In what situation is it useful for a qube to be able to access its immediate 
> neighbors?

Explained on that page: most useful is file exchange with no Qubes
tools installed, but also for testing network code, new pgp or ssh
keys, etc.

> 
> All the best
> Michael
> 

-- 
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/20210717102948.GG419%40thirdeyesecurity.org.


Re: [qubes-users] Re: Safely set up a Qube to connect to only one IP address on the Internet

2021-07-15 Thread unman
On Wed, Jul 14, 2021 at 04:35:42PM +, Michael Singer wrote:
> > On Wed, Jul 14, 2021 at 04:40:29, unman wrote:
> 
> > Disable all unnecessary services in the qube - that means almost all of
> > them.
> 
> Where would you look for such services?

Look to see what's running in the template/qube.

> 
> Would you let my Qube, which is supposed to connect to only one IP address on 
> the internet, be based on an extra firewall-vm? Would that more secure?
You could do this: it would have one particular advantage, in that you
could set custom rules in sys-net to restrict access from that
sys-firewall to the specified IP address.
 
> 
> In the Qube settings for the services there is the service 
> "disable-default-route". I have not found anything about what it does. In my 
> case, would it be better to leave it on or turn it off?
> 
man qvm-service - this service will remove the default gateway entry. So
a qube would be able to access immediate neighbours but not step beyond.
It's not what you want here.

-- 
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/20210715115023.GG20432%40thirdeyesecurity.org.


Re: [qubes-users] Safely set up a Qube to connect to only one IP address on the Internet

2021-07-14 Thread unman
On Mon, Jul 12, 2021 at 11:02:51AM +, Michael Singer wrote:
> Dear Qubes community,
> 
> i am interested in your ideas on how you would set up a Qube as secure as 
> possible to connect to a single ordinary internet site (not a VPN network) 
> accessed directly via its IP address.
> 
> My ideas are:
> 
> 1) Edit the Qube's firewall via dom0 as follows:
> 
> $dom0: qvm-firewall NAME-OF-QUBE del --rule-no 0
> $dom0: qvm-firewall NAME-OF-QUBE add --before 0 drop
> $dom0: qvm-firewall NAME-OF-QUBE add --before 0 accept 127.127.127.127/32 
> proto=tcp 443
> 
> 2) Go into the dom0-Qube settings and turn on the disable-dns-server service.
> 
> With these two settings, there should really be no DNS traffic anymore, right?
> 
> What else would you do?
> 
> Best wishes
> Michael Singer
> 

These are good.
Disable all unnecessary services in the qube - that means almost all of
them.
Change the nft/iptables configuration on the qube itself - note that you
can do this in `/rw/config/rc.local` but that is processed after the
network comes up.
You want to allow only outbound lo and to your target.
Remove/overwrite /etc/resolv.conf

You can also create an alias in /etc/hosts to avoid typing out the full
IP address.

-- 
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/20210714114023.GC13317%40thirdeyesecurity.org.


Re: [qubes-users] Question related to Qubes Updater of dom0

2021-07-11 Thread unman
On Sun, Jul 11, 2021 at 01:13:04AM -0700, Viktor Ransmayr wrote:
> Hello unman,
> 
> unman schrieb am Samstag, 10. Juli 2021 um 16:57:43 UTC+2:
> 
> > Looks good to me 
> >
> 
> Can you please elaborate a bit more! - What were you looking for?

I was looking for a problem with the update process.
There has been a long thread in the forum about why you should use the
updated tool instead of updating locally. In brief, it's used to apply
other things (e.g. configuration changes) besides raw updates.

> 
>- Why is 'qubes updater' notified in the first place, if nothing needs 
>to be done? - OR -
>
> 
>- If something got done 'locally', why isn't at least a minimal 
>information about the performed activity returned?
> 
> This inconsistency / uncertainty is confusing (at least to me ).

Because the updater does more than just update, it is possible that
there are things not applied.

What's the situation here? What Qubes version are you on? Do you mean
that dom0 is always marked a requiring updates in the updater tool?
Is it still showing that updates are required?

-- 
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/20210711105246.GA9877%40thirdeyesecurity.org.


Re: [qubes-users] Question related to Qubes Updater of dom0

2021-07-10 Thread unman
Looks good to me

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


Re: [qubes-users] Question related to Qubes Updater of dom0

2021-07-10 Thread unman
On Fri, Jul 09, 2021 at 12:22:29PM -0700, Viktor Ransmayr wrote:
> Viktor Ransmayr schrieb am Donnerstag, 8. Juli 2021 um 23:11:33 UTC+2
> 
> > Am Do., 8. Juli 2021 um 22:05 Uhr schrieb Mike Keehan :
> >
> >> On 7/8/21 7:27 PM, Viktor Ransmayr wrote:
> >> > Hello Qubes Community,
> >> > 
> >> > I have received multiple requests to accept an update of 'dom0' content 
> >> > lately.
> >> > 
> >> > The only info I've received after performing these updates has been:
> >> > 
> >> > ###
> >> > 
> >> > Updating dom0
> >> > 
> >> > local:
> >> >  --
> >> > 
> >> > ###
> >> > 
> >> > Can someone provide an explanation, a link to read more about it - or - 
> >> > should I be worried?
> >>
> >> Have you "blacklisted" any packages.  I get the same messages as above
> >> but that is because I have told RPM to ignore the intel video driver 
> >> update - it hangs my screen after a random time interval.
> >>
> >
> > No I have not  "blacklisted" any packages.
> >
> 
> Same behaviour happened again just now!
> 
> Is there any way to get more information (i.e. announcements, logs, 
> notifications etc.)?
> 
> Viktor
> 

What's the result of running `sudo qubes-dom0-update` in dom0 terminal?

-- 
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/20210710124853.GB4329%40thirdeyesecurity.org.


Re: [qubes-users] Debian onion repo v2 deprecation - any debian v3 onions alternatives

2021-07-06 Thread unman
On Tue, Jul 06, 2021 at 10:00:23AM +, 'taran1s' via qubes-users wrote:
> I have my debian based templates updating repos onionized through existing
> v2 onions. Tor Project announced that it will deprecate the v2 onions. Are
> there any alternative debian v3 onions for debian updates?
> 

The Qubes onion repos are v3.
If you have updated apt-transport-tor, then you should already be using
v3 onions.

Take a look at https://onion.debian.org - Debian are v3 ready.

-- 
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/20210706114352.GA26563%40thirdeyesecurity.org.


Re: [qubes-users] Updating templates via salt (update.qubes-vm) doesn't work

2021-07-03 Thread unman
On Sat, Jul 03, 2021 at 03:43:31PM +0200, 799 wrote:
> Hello,
> 
> I am trying to learn more about SALT in Qubes OS. In the past I have
> written my setup scripts to setup "my qubes" from a fresh installation, now
> I'd like to use SALT for it.
> 
> I have installed a default Qubes on which the sys-vms are based on the
> fedora-32 template.
> 
> If I enter in dom0:
> 
> sudo qubesctl --targets fedora-32 update.qubes-vm
> 
> ... which should update the template I get the following error:
> 
> 'update.qubes-vm' is not available.
> DOM0 configuration failed, not working
> 
> Any idea what went wrong?
> 
> 799
> 

By default, qubesctl will act on dom0.
You've referenced a state, but need to apply it.

sudo qubesctl --show-output --skip-dom0 --targets fedora-32 state.apply 
update.qubes-vm

I have a basic introduction at https://github.com/unman/notes in the
salt folder.

-- 
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/20210703151645.GB8865%40thirdeyesecurity.org.


Re: [qubes-users] USB controllers

2021-07-01 Thread Unman
On Mon, Jun 21, 2021 at 11:22:01PM -0300, Franz wrote:
> >
> Other strange things happened:
> To restore a backup I connected an external USB disk with the backup to the
> second USB qube and under the restore command I clicked on the external USB
> disk to mount it. When I did that, a black background message on the upper
> right part of the screen told me that the disk was removed, while, at the
> same time it was NOT removed at all because the triangle showed that the
> disk was mounted and the  content of the external USB disk was shown. Using
> my old and trusted x230 for many years this never happened. So I suppose it
> is strange.
> 
> Also, the computer seems much slower than my old x230, which is strange
> being a new computer
> 
> If you want me to try commands and report results, just ask, I am very
> willing to do anything that may be helpful to solve these problems.
> best

Hi Franz

Sorry for the radio silence. I'll dig in to the logs you provided in
the morning.
At this stage I would *seriously* be thinking of looking for a refund or
replacement - you simply shouldn't be having these issues with a new
computer, particularly if you had told them you would be running Qubes.

Is it possible for you to boot a live distro from USB and see if the
same issues exist?

-- 
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/20210701133325.GB26428%40thirdeyesecurity.org.


Re: [qubes-users] Re: Impossible to upgrade Fedora template from 32 to 34

2021-06-26 Thread unman
On Sat, Jun 26, 2021 at 04:22:54AM -0700, Ashtarsheran wrote:
> Another thing, I did try increasing memory as per the Troubleshooting doc 
> on this template ; but this didn't solve anything in my case :/
> 
> On Saturday, 26 June 2021 at 13:20:39 UTC+2 Ashtarsheran wrote:
> 
> >
> > Hi all, 
> >
> > I've been having a hard time upgrading my Fedora template from 32 to 34. I 
> > know it's a bit late for that, but actually thought I had managed a first 
> > time, turned out I was still using 32. Anyway here's what I've been 
> > attempting:
> >
> > 1: Deciding initially to go for the advanced user method and followed each 
> > step very precisely. On several occasions, the VM template ugrade 
> > completes. But when restarting the template afterwards, fedora 34 hangs and 
> > I get the qxerec error, here: 
> >
> > *domain deadcannot connect to qrexec agent: No such file or directory*
> >
> > 2: I decided to settle for the recommended install method for beginners. 
> > Failure here as well getting the message: 
> > *Cannot mkdir, no space left. *
> >

Are you moving directly from 32 to 34? It sounds like it.
I think you should upgrade from 32 to 33, confirm that is working,
and then run the upgrade to 34. Dont forget to upgrade the Qubes
repositories at the same time.

It would be helpful if you could post any error messages you see in the
actual upgrade process.

The recommended install method for beginners would be to install a
fedora-34 template, and that isn't available yet. Can you explain what
you meant by this?

Using a custom template may cause a problem, but you should see in the
logs whether you have installed all the necessary Qubes components.

-- 
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/20210626120219.GE15430%40thirdeyesecurity.org.


Re: [qubes-users] How to assign keyboard shortcuts to a VM?

2021-06-23 Thread unman
On Tue, Jun 22, 2021 at 07:15:22PM -0500, Sven Semmler wrote:
> Hi Michael,
> 
> I don't have the time currently to figure this out and send you a working
> solution. So instead I'll share things I know:
> 
> 1) if you inquire the window property "_QUBES_VMNAME" of the active window,
> you'll get the name of the qube
> 
> 2) you should be able to get to this with wmctrl or maybe xdotool
> 
> Then write a little bash script in dom0 and hook it up to a shortcut, is
> what I think.
> 
> Good luck!
> 
> /Sven

Here's a script that does exactly this.
Edit it to do something with $QUBE.
Associate it with a shortcut.

```
#!/bin/bash
ID=`xdotool getwindowfocus`
QUBE=`xprop _QUBES_VMNAME -id $ID|cut -f2 -d\" `
if [[ "$QUBE" == "_QUBES_VMNAME:  not found." ]]; then
  exit
else
# Do something with $QUBE
fi
```

The if clause is to exclude dom0 windows, but you could adapt that if
you *do* want action in dom0.

unman

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


Re: [qubes-users] Dual booting different Qubes versions on same machine

2021-06-22 Thread unman
On Tue, Jun 22, 2021 at 10:29:54AM +0100, River~~ wrote:
> Hi all,
> 
> I noticed the new "alpha" level isos in the downloads and feel
> motivated to help testing it.
> 
> I obviously do not want to go over to alpha for my normal work, but
> would be interested if I can install it alongside my existing current
> release. That way I would be testing that it works on the exact
> hardware that I would eventually be running it on when it reaches
> production quality.
> 
> Do I proceed as for the instructions for installing Qubes as a second
> boot option to Linux? If not, what would be different?
> 
> What additional risks might I introduce by running a development
> version of Qubes on the same physical machine as the production
> version?
> 
> Obviously I would not have any files/partitions shared apart from the
> EFI partition.
> 
> Would it make sense to install it onto an EFI partition on a different
> internal disk? Would it be better for any reason to install it onto a
> USB drive? (my guess to both of these is no, because when the test
> system is running the production system would be on the host even if
> not mounted)
> 
> My current production version is R4.0.3 and I will shortly be
> replacing it with R4.0.4. At the time of writing the current alpha is
> R4.1.0 but that my (or may not) change by the time I get around to
> installing it.
> 
> I thought I would dual boot the new R4.0.4 with the existing R4.0.3,
> then once R4.0.4 is verified as working for me I would transfer the
> user level files and then overwrite the older production version with
> the alpha test version. Anyone who can think why that might be a bad
> idea please speak now or forever hold your peace (as they say in
> English weddings)
> 
> I did a google search for "dual boot qubes versions site:qubes-os.org"
> but it only pointed me to info about dual booting with non-Qubes
> systems.
> 
> Once successful, would ppl welcome my spending time adding a section
> to the dual boot online documentation? I would be happy to do so if
> just one person thinks it might be useful
> 
> WArmly
> River~~

With classic GRUB it's straightforward, and (imo) doesn't warrant new
docs.
I cant help with UEFI at all, and that probably *does*.

That said, you would be running alpha software alongside your main
system. Having separate encrypted drives/partitions will undoubtedly aid
separation, but it's still a risk, and not something I would advocate if
you value your data.
If it's possible for you to swap out your drives, and have a separate
4.1 drive, I would recommend that instead.

-- 
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/20210622110657.GE20642%40thirdeyesecurity.org.


Re: [qubes-users] Troubleshooting: ArchLinux install seems to be stuck, logs attached

2021-06-21 Thread unman
On Mon, Jun 21, 2021 at 08:57:07AM -0400, Haisam Khalil wrote:
> On Mon, Jun 21, 2021 at 6:52 AM unman  wrote:
> 
> > On Sun, Jun 20, 2021 at 09:14:47AM -0700, Chrome wrote:
> > >
> > > Doesn't matter because I give up on this approach or the debian
> > approach. I
> > > nuked the fedora 32 minimal template and will give it a fresh start.  I
> > can
> > > tell you for sure I followed your instructions and the documentation and
> > > got no further than I was when I started this post.
> > >
> > > Starting fresh: how would you install ArchLinux in preparation for
> > > installing blackarch on top of it?
> > >
> >
> > Good luck with the build - use a 33 template, turn up logging and post
> > your results.
> > If you want a prebuilt template, I have recent builds at
> > https://qubes.3isec.org
> 
> thank you unman, I???ll run man on the commands to figure out the logging.
> I???ll post up when done. Appreciate all the help to date.
> 
> > <https://qubes.3isec.org>
> >
> -- 
> Best,

There are "DEBUG" and "VERBOSE" settings in builder.conf, explained in
doc/Configuration.md
Those parameters will impact on the log files in build-logs (in
particular I think having them set will not create a log file for the
template build), but they will produce a far more verbose output.

This should help you to identify where the problem lies.
Best of luck

-- 
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/20210621130751.GA15648%40thirdeyesecurity.org.


Re: [qubes-users] VPN up/down pop up not working?

2021-06-21 Thread unman
On Mon, Jun 21, 2021 at 11:53:17AM +, Stumpy wrote:
> On 2021-06-18 03:15, Sven Semmler wrote:
> > On 6/17/21 8:59 AM, Stumpy wrote:
> > > I guess I will just grin and bear it as its not crucial, I was just
> > > hoping the fix might be simple like Sven's suggestion (thanks for
> > > the suggestion though Sven!).
> > 
> > No problem. To further drill down and what could be the cause ... what
> > happens when you type
> > 
> > notify-send test
> > 
> > in your VPN qube? I am guessing, but there is a very high chance
> > that's exactly what the qtunnel script will call.
> > 
> > /Sven
> > 
> > --
> >  public key: https://www.svensemmler.org/2A632C537D744BC7.asc
> > fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7
> 
> Hi Sven,
> Thanks for the follow up.
> When I type notify-send test in the vpn appvm a small notification "send"
> pops up in the top right side of my screen, that seems like a positive sign?
> 
> Btw, per unman's question, I installed CentOS full template and tried
> starting the vpn appvm and nothing happened, then tried using the full fed33
> template and I got the vpn up popup.
> 
> Cheers
> 

So, it would seem to be a Centos issue, and not a "minimal template"
issue.

-- 
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/20210621122059.GA15434%40thirdeyesecurity.org.


Re: [qubes-users] Troubleshooting: ArchLinux install seems to be stuck, logs attached

2021-06-21 Thread unman
On Sun, Jun 20, 2021 at 09:14:47AM -0700, Chrome wrote:
> 
> Doesn't matter because I give up on this approach or the debian approach. I 
> nuked the fedora 32 minimal template and will give it a fresh start.  I can 
> tell you for sure I followed your instructions and the documentation and 
> got no further than I was when I started this post.
> 
> Starting fresh: how would you install ArchLinux in preparation for 
> installing blackarch on top of it?
> 

Good luck with the build - use a 33 template, turn up logging and post
your results.
If you want a prebuilt template, I have recent builds at
https://qubes.3isec.org

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


Re: [qubes-users] Troubleshooting: ArchLinux install seems to be stuck, logs attached

2021-06-20 Thread unman
On Sun, Jun 20, 2021 at 08:29:14AM -0700, Chrome wrote:
> 
> > I've tried with a Fedora-33-minimal base for the builder (I usually use 
> > Debian), and the Archlinux template builds fine. 
> > As I said, there are two problems : first, you're just not building all 
> > the required packages. I don't see how this is happening - if you run 
> > setup, and then `make qubes-vm` you *will* get all the required 
> > packages, or will see feedback on where a package build has failed.. 
> >
> > You can turn on DEBUG and increase verbosity by editing builder.conf. 
> > BUT, you should also have build-logs which you can inspect. 
> > Try `make clean-rpms`, delete builder.conf, run setup.sh, increase 
> > verbosity, `make get-sources`, `make qubes-vm`. 
> > Watch for any errors. 
> > If all is well, then `make template` 
> >
> > I gave this a go with the fedora-32 template and still had issues. I think 
> doing the debian thing would probably be better. Should I just clone my 
> debian-10 template and try the steps again?
> 

No, because you will have to find the Debian equivalents to the Fedora
packages, and frankly, if you cant get it workign on Fedora (which is
supported), then you are not likely to get it working on Debian (which
isnt).

What issues did you have?
What did it show in the logs?

-- 
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/20210620160604.GA10341%40thirdeyesecurity.org.


Re: [qubes-users] Troubleshooting: ArchLinux install seems to be stuck, logs attached

2021-06-18 Thread unman
On Thu, Jun 17, 2021 at 05:22:57AM -0700, Chrome wrote:
> 
> 
> On Thursday, June 17, 2021 at 8:03:36 AM UTC-4 unman wrote:
> 
> > On Wed, Jun 16, 2021 at 10:02:34AM -0700, Chrome wrote: 
> > > qubes downloading... 
> > > error: failed retrieving file 'qubes.db' from disk : Couldn't open file 
> > > /tmp/qubes-packages-mirror-repo/pkgs/qubes.db 
> > > error: failed to synchronize all databases (download library error) 
> > > 
> > > 
> >
> > Strange - as I say, works for me. 
> > What template are you using for the build machine? 
> > With debug on do you see any issues with the initial mount of the local 
> > repository? 
> >
> > How do I turn debug on? What commands should I try running?
> 
> As for the template, I'm using fedora 32 minimal. I understood the 
> following steps of the guide to be executed as follows:
> https://github.com/Qubes-Community/Contents/blob/master/docs/building/building-archlinux-template.md
> Step 0: Dom 0 terminal for all commands
> Step 1: open non root xterm in templateVM Fedora32minimal, execute commands
> Step 2: Setup appvm build-archlinux2 and set it up per guide and pictures
> Step 3-6: All run in appvm terminal per instructions.
> 
> If I did something wrong, I don't know what it is. I think the instructions 
> given are quite sparse for the issues I'm encountering. But that can't be 
> helped huh?
> 

I've tried with a Fedora-33-minimal base for the builder (I usually use
Debian), and the Archlinux template builds fine.
As I said, there are two problems : first, you're just not building all
the required packages. I don't see how this is happening - if you run
setup, and then `make qubes-vm` you *will* get all the required
packages, or will see feedback on where a package build has failed..

You can turn on DEBUG and increase verbosity by editing builder.conf.
BUT, you should also have build-logs which you can inspect.
Try `make clean-rpms`, delete builder.conf, run setup.sh, increase
verbosity, `make get-sources`, `make qubes-vm`.
Watch for any errors.
If all is well, then `make template`

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


Re: [qubes-users] VPN up/down pop up not working?

2021-06-17 Thread unman
On Thu, Jun 17, 2021 at 01:59:23PM +, Stumpy wrote:
> Anyway, I am not at a level that I can do particuarly deep poking and
> figuring out such things, though the community has been a great resource in
> helping me improve my "qubes/linux kungu". I do remember getting this popup
> before (like a year ago) with centos and am pretty sure it would "just work"
> with fedora, i just prefer centos minimal as its less crufty with other
> things installed and has a much longer upgrade cycle (is that the word for
> it?) than fedora which for the purposes of proxy vms I am certainly not
> looking for bleeding edge, just secure and can just "set it and forget it"
> :)
> 
> I guess I will just grin and bear it as its not crucial, I was just hoping
> the fix might be simple like Sven's suggestion (thanks for the suggestion
> though Sven!).
> 
> Cheers
> 

Thanks for the way you took that. I wasn't trying to put you off - you
have done *exactly* the right thing by checking here.
Have you checked that everything works with a full centos template?

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


Re: [qubes-users] Troubleshooting: ArchLinux install seems to be stuck, logs attached

2021-06-17 Thread unman
On Wed, Jun 16, 2021 at 10:02:34AM -0700, Chrome wrote:
>  qubes downloading...
> error: failed retrieving file 'qubes.db' from disk : Couldn't open file 
> /tmp/qubes-packages-mirror-repo/pkgs/qubes.db
> error: failed to synchronize all databases (download library error)
>  
> 

Strange - as I say, works for me.
What template are you using for the build machine?
With debug on do you see any issues with the initial mount of the local
repository?

-- 
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/20210617120331.GC22344%40thirdeyesecurity.org.


Re: [qubes-users] VPN up/down pop up not working?

2021-06-17 Thread unman
On Thu, Jun 17, 2021 at 10:55:46AM +, Stumpy wrote:
>  
> 
> On 2021-06-17 07:42, Sven Semmler wrote:
> > Do you have a notification daemon installed? If unsure, install and
> > run dunst and see if it works then.
> 
> Thanks. I pretty much installed the packages listed as being needed for
> centos minimal to function as a proxy [1], one of them being
> "notification-daemon" which I assumed was what was needed. I went back
> and double checked that I had it installed and it was:

You know, minimal templates come with a health warning for a reason.
They expect, (and often require) a level of understanding and
experience.

Important

The Minimal TemplateVMs are intended only for advanced users. If
you encounter problems with the Minimal TemplateVMs, we recommend
that you use their standard TemplateVM counterparts instead.

If something works with a standard TemplateVM but not the minimal
version, this is most likely due to user error (e.g., a missing
package or misconfiguration) rather than a bug. In such cases, please
do not file a bug report. Instead, please see Help, Support, Mailing
Lists, and Forum for the appropriate place to ask for help. Once
you have learned how to solve your problem, please contribute what
you learned to the documentation.

Make sure that everything works in a standard template, and then look to
see what relevant packages are installed there compared to what you have,
and then check back here.

-- 
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/20210617112957.GB22344%40thirdeyesecurity.org.


Re: [qubes-users] Troubleshooting: ArchLinux install seems to be stuck, logs attached

2021-06-16 Thread unman
On Tue, Jun 15, 2021 at 06:31:37AM -0700, Chrome wrote:
> 
> 
> On Tuesday, June 15, 2021 at 8:00:17 AM UTC-4 unman wrote:
> 
> > I'm not familiar with the document you are referring to. 
> > I regularly build the Arch templates, and dont recognise these errors. 
> > It looks as if a) you haven't built some of the packages, and b) the 
> > package database isn't being attached to the template. 
> > Are you using the setup script? 
> > The Arch template is simply built using standard setup: 
> > Run setup. 
> > make get-sources 
> > make qubes-vm 
> > make template. 
> >
> > I'm not sure why that would warrant a dedicated document. 
> > Have you tried that? 
> >
> https://github.com/Qubes-Community/Contents/blob/master/docs/os/pentesting/blackarch.md
> 
> I'm really following this step and step 1 is to install arch linux minimal 
> via the previously posted guide. I'm going to try to follow your 
> instructions this time but yeah, that's why I'm following that 
> documentation; its what I find when I go to the official qubes 
> documentation site under "External Documentation."
> 

It's far too wordy for my taste, and image heavy.
Still, the basic is *exactly* what I suggested, and that works for
building a template. 
See if you can build the arch template: not minimal.

-- 
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/20210616102639.GD14966%40thirdeyesecurity.org.


Re: [qubes-users] Troubleshooting: ArchLinux install seems to be stuck, logs attached

2021-06-15 Thread unman
I'm not familiar with the document you are referring to.
I regularly build the Arch templates, and dont recognise these errors.
It looks as if a) you haven't built some of the packages, and b) the
package database isn't being attached to the template.
Are you using the setup script?
The Arch template is simply built using standard setup:
Run setup.
make get-sources
make qubes-vm
make template.

I'm not sure why that would warrant a dedicated document.
Have you tried that?

-- 
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/20210615120012.GF8521%40thirdeyesecurity.org.


Re: [qubes-users] Troubleshooting: Kali VM creation Error: E: The method driver /usr/lib/apt/methods/tor+http could not be found. N: Is the package apt-transport-tor installed?

2021-06-13 Thread unman
On Sat, Jun 12, 2021 at 09:26:11AM -0700, Chrome wrote:
> https://github.com/Qubes-Community/Contents/blob/master/docs/os/pentesting/kali.md
> 
> Currently at step 9 of creating a usable kali VM when I saw the following 
> terminal text. Did something qubes related get removed from the template 
> when upgrading to bullseye or attempting to upgrade to bullseye? Thank you 
> for any help you can give.
> 
> user@kali-rolling:~$ sudo apt update
> Hit:2 https://deb.qubes-os.org/r4.0/vm bullseye 
> InRelease  
> Hit:3 https://deb.qubes-os.org/r4.0/vm bullseye-testing InRelease  
> Hit:1 https://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease
> Hit:4 https://deb.qubes-os.org/r4.0/vm bullseye-securitytesting InRelease
> Reading package lists... Done
> E: The method driver /usr/lib/apt/methods/tor+http could not be found.
> N: Is the package apt-transport-tor installed?
> E: The method driver /usr/lib/apt/methods/tor+http could not be found.
> N: Is the package apt-transport-tor installed?
> E: The method driver /usr/lib/apt/methods/tor+http could not be found.
> N: Is the package apt-transport-tor installed?
> E: Failed to fetch 
> tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/vm/dists/bullseye/InRelease
>  
>  
> E: Failed to fetch 
> tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/vm/dists/bullseye-testing/InRelease
>  
>  
> E: Failed to fetch 
> tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/vm/dists/bullseye-securitytesting/InRelease
>  
>  
> E: Some index files failed to download. They have been ignored, or old ones 
> used instead.
> 

The error message tells you all you need to know.
Install the apt-transport-tor  package.

There are pre-built Tor Templates available for 4.0 and 4.1, if you
want.

-- 
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/20210613114608.GF28112%40thirdeyesecurity.org.


Re: [qubes-users] USB controllers

2021-06-13 Thread Unman
Very sorry to hear of your problems.
Equally happy to help you (as far as I can) with resolving these issues,
so if you do want to keep working on this, let the list know how it
goes, and we will provide whatever help we can.

-- 
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/20210613112201.GA28112%40thirdeyesecurity.org.


Re: [qubes-users] USB controllers

2021-06-12 Thread Unman
On Sat, Jun 12, 2021 at 08:23:48AM -0300, Franz wrote:
> >
> >> take a look to the `qvm-pci` man page, it explains how to detach.
> >>
> >>
> >>
> > Many thanks it worked perfectly
> >
> 
> It worked perfectly for a week or so, then the mouse stopped working.
> Thomas at Vikings, who built the D8 computer with preinstalled coreboot,
> says it should be a Qubes issue.
> 
> How may I tell if it is a Qubes issue or a hardware issue?
> best
> 

You aren't clear on what is happened here, because you haven't provided
sufficient detail..
Do you mean that you allocated a USB controller to a sys-usb, to use
with the mouse. After a week, the mouse stopped working.
When both controllers were attached to a single usb-qube the mouse
worked without interruption.
Is that the position?

Did the other USB qube continue to work?
If you type lsusb in the "mouse"-usb do you see the mouse attached?
If you attach another usb device, does lsusb and dmesg show the device
being attached?
If you attach the mouse to the *other* usb qube, does it appear there?
If you revert to a single usb qube, does the mouse work for more than a
week there?
If you move the mouse to the other controller, does the mouse work for
more than a week?

Let's think about this.
Many Qubes users will be using coreboot.
Many Qubes users will be using more than one usb qube.
Many Qubes users use a usb mouse for more than one week without
incident.
What is different about you? Coreboot, Your hardware.
I am not saying that your hardware is at fault - it's just that the most
likely source is *your configuration and hardware in Qubes*.

Of course, if Vikings can point to other users with your hardware and
coreboot build who use Qubes without a problem, that would help too.

I would prepare another usb mouse, that can work with the other usb
qube. Use your mouse-usb qube until it "breaks". Plug the mouse in to
the other usb qube, and start looking at the "broken" usb qube.
Look in logs, for any events that might be associated with the loss of
mouse. Remove and reinsert the broken mouse to see how it is handled.
Remove and reinsert other usb devices to see how they are handled.
journalctl, dmesg are your friends, as well as basic troubleshooting.
(Another mouse, use the other controller, etc)


-- 
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/20210612115155.GA22044%40thirdeyesecurity.org.


Re: [qubes-users] snap issues, related to the filesystem outside of ~/ ?

2021-06-11 Thread unman
On Thu, Jun 10, 2021 at 09:45:59PM +, Stumpy wrote:
>  
> 
> I tried installing snaps in a debian template and then 
> 
> but while it ran fine the first time, after restarting it stopped
> working. As I wanted to be sure it was not a qubes issue I posted on the
> snapcraft forum [1] and the question they asked that made me think it
> was qubes related was
> 
>  _"Is this being run inside a container? It seems to imply that either
> /dev or /tmp/snap.rootfs_IeI049/ do not exist, but previously in the log
> the tmp dir was created by snap-confine"_
> 
> So, AFAIK i installed it according to the qubes instructions [2] but am
> getting various errors that are starting to point to the ephemeral
> nature of appvms (only the home dir is retained).
> 
> Anyone know how to fix this?
>  
> 
> Links:
> --
> [1]
> https://forum.snapcraft.io/t/authy-snap-error-cannot-perform-operation-mount-rbind/24932
> [2]
> https://www.qubes-os.org/doc/software-update-domu/#installing-snap-packages
> 

Snaps now litter across the file system, so are no longer the
user-specific install they seemed to be.
I don't think there is a simple fix - you cant use bind-dirs for the
devices under /dev, and I'm guessing the /tmp directory is created per
boot.

-- 
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/20210611122546.GF15508%40thirdeyesecurity.org.


Re: [qubes-users] notify-send

2021-06-09 Thread unman
On Wed, Jun 09, 2021 at 05:07:58PM +0200, haaber wrote:
> Hello,
> 
> you someone remind me which qubes package contains the "notify-send"
> command? Thank you
> 

Not Qubes package - libnotify

-- 
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/20210609154126.GB4661%40thirdeyesecurity.org.


Re: [qubes-users] Need help troubleshooting four program installs (EyeWitness/theHarvester/pipenv/kazam) for Fedora based OSINT VM

2021-06-08 Thread unman
On Tue, Jun 08, 2021 at 06:38:44AM -0700, Chrome wrote:
> 
> Good Morning again,
> 
> I got the OSINT VM about 95% setup. Thank you all for your help on it. I 
> ran into problems during the install of a few recommended tools in the Mike 
> Bazzell OSINT manual. These programs are as follows: EyeWitness, 
> theHarvester, pipenv, and kazam.
> 
> Kazam seems like something I don't actually need but I'd still like all 
> tools set up. Below is the terminal text I saved in a "todo" txt file. Any 
> help understanding the error messages and what I need to do to resolve them 
> would be appreciated. I recognize everyone on here is quite busy but this 
> n00b would definitely appreciate the help. Thank you.


You have not said where, or how, you are trying to install these - in Template,
Standalone, or template based qube.

> 
> =
> 1. Fix Eyewitness
> ###
> #  EyeWitness Setup   #
> ###
> 
> [Error]: \S is not supported by this setup script.

Clear - look in the setup script. You are using a parameter "\S" that is
not supported.

> 
> [user@OSINT-Template setup]$ 
> 
> 2. Fix theHarvester
> 3. Fix pipenv


You have repeated error 502 - this is "Bad Gateway"- change your routing
to these sites.
You do not have right python installed - the requirement is specific -
>=2.7, but less than 3.0.
Install and configure your python(s) as necessary.

> 4. Fix kazam
> [user@OSINT-Template kazam-1.4.4]$ sudo python3 setup.py install
> Traceback (most recent call last):
>   File "setup.py", line 8, in 
> from DistUtilsExtra.command import *
> ModuleNotFoundError: No module named 'DistUtilsExtra'
> [user@OSINT-Template kazam-1.4.4]$ 
> 

You need to install DistUtilsExtra - in Debian based qubes you should
install python-distutils-extra or python3-distutils-extra , depending on
your python version.

-- 
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/20210608144025.GB28999%40thirdeyesecurity.org.


Re: [qubes-users] USB controllers

2021-06-02 Thread unman
On Wed, Jun 02, 2021 at 09:03:46AM -0300, Franz wrote:
> Hello all,
> 
> After standard installation using a PS2 keyboard, I should have two
> separate usb controllers in the same sys-usb qube. I would prefer to have
> two distinct sys-usb so using one more secure for the mouse (PS2 mouse does
> not work) that should be somehow connected to dom0 and the other less
> secure for external USB disks.
> i carefully examined the Qubes papers
> https://www.qubes-os.org/doc/usb-qubes/#enable-a-usb-keyboard-for-login
> but I am still very confused.
> Which is the proper way to do that?
> Best Franz
> 

You can simply qvm-clone the existing sys-usb, and then fix up the
controller allocation between the two.
You can also set autostart with qvm-prefs for the "less secure" so that
it is not started by default. This will mean that you have to
consciously start that usb qube if you want to use external devices.
You might also consider using udev rules, or blacklisting modules in the
"mouse" usb, so that it cannot be used with other USB devices.

-- 
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/20210602134220.GE26296%40thirdeyesecurity.org.


Re: [qubes-users] qubes-dom0-update (https://github.com/QubesOS/qubes-issues/issues/6581)

2021-05-26 Thread unman
On Wed, May 26, 2021 at 04:22:39PM +0200, Ulrich Windl wrote:
> Hi!
> 
> I know that the issue is marked fixed already, but I wonder if there should
> have been some more popular notice for this surprising change in the update
> mechanism.
> 
> Today I saw there (before installing updates):
> [master@dom0 ~]$ sudo qubes-dom0-update
> Using sys-firewall as UpdateVM to download updates for Dom0; this may take
> some time...
> warning: Converting database from bdb to sqlite backend
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo; Configuration:
> OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo; Configuration:
> OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo; Configuration:
> OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora-updates.repo;
> Configuration: OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora-updates.repo;
> Configuration: OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora-updates.repo;
> Configuration: OptionBinding with id "failovermethod" does not exist
> Warning: Enforcing GPG signature check globally as per active RPM security
> policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message)
> 
> Today's updates were:
> pm-plugin-systemd-inhibit-4.14.2.1-5.fc25.x86_64 Wed 26 May 2021 03:34:19 PM
> CEST
> rpm-plugin-selinux-4.14.2.1-5.fc25.x86_64 Wed 26 May 2021 03:34:19 PM
> CEST
> qubes-rpm-oxide-0.2.2-1.fc25.x86_64   Wed 26 May 2021 03:34:19 PM
> CEST
> qubes-mgmt-salt-dom0-4.0.25-1.fc25.noarch Wed 26 May 2021 03:34:19 PM
> CEST
> qubes-core-dom0-linux-kernel-install-4.0.30-1.fc25.x86_64 Wed 26 May 2021
> 03:34:19 PM CEST
> qubes-core-dom0-linux-4.0.30-1.fc25.x86_64Wed 26 May 2021 03:34:19 PM
> CEST
> python3-rpm-4.14.2.1-5.fc25.x86_64Wed 26 May 2021 03:34:19 PM
> CEST
> python2-rpm-4.14.2.1-5.fc25.x86_64Wed 26 May 2021 03:34:19 PM
> CEST
> rpm-sign-libs-4.14.2.1-5.fc25.x86_64  Wed 26 May 2021 03:34:12 PM
> CEST
> rpm-libs-4.14.2.1-5.fc25.x86_64   Wed 26 May 2021 03:34:12 PM
> CEST
> rpm-build-libs-4.14.2.1-5.fc25.x86_64 Wed 26 May 2021 03:34:12 PM
> CEST
> rpm-4.14.2.1-5.fc25.x86_64Wed 26 May 2021 03:34:12 PM
> CEST
> qubes-mgmt-salt-config-4.0.25-1.fc25.noarch   Wed 26 May 2021 03:34:12 PM
> CEST
> qubes-mgmt-salt-base-config-4.0.2-1.fc25.noarch Wed 26 May 2021 03:34:12 PM
> CEST
> qubes-mgmt-salt-base-4.0.4-1.fc25.noarch  Wed 26 May 2021 03:34:12 PM
> CEST
> qubes-mgmt-salt-admin-tools-4.0.25-1.fc25.noarch Wed 26 May 2021 03:34:12 PM
> CEST
> qubes-mgmt-salt-4.0.25-1.fc25.noarch  Wed 26 May 2021 03:34:12 PM
> CEST
> 
> When re-trying after those updates, (most of) the message is still there:
> Using sys-firewall as UpdateVM to download updates for Dom0; this may take
> some time...
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo; Configuration:
> OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo; Configuration:
> OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo; Configuration:
> OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora-updates.repo;
> Configuration: OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora-updates.repo;
> Configuration: OptionBinding with id "failovermethod" does not exist
> Invalid configuration value: failovermethod=priority in
> /var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora-updates.repo;
> Configuration: OptionBinding with id "failovermethod" does not exist
> Warning: Enforcing GPG signature check globally as per active RPM security
> policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message)
> Last metadata expiration check: 0:41:44 ago on Wed May 26 15:33:47 2021.
> Dependencies resolved.
> =
>  PackageArchVersion Repository
> Size
> 

Re: [EXT] Re: [qubes-users] Dom0 update error (Converting database from bdb to sqlite backend)

2021-05-26 Thread unman
On Wed, May 26, 2021 at 04:11:44PM +0200, Ulrich Windl wrote:
> On 5/14/21 3:22 PM, unman wrote:
> > On Fri, May 14, 2021 at 05:30:30AM -0700, load...@gmail.com wrote:
> > > On Wednesday, May 12, 2021 at 10:00:16 PM UTC+3 awokd wrote:
> > > 
> > > > load...@gmail.com:
> > > > > On Monday, May 10, 2021 at 10:06:10 PM UTC+3 awokd wrote:
> > > > 
> > > > 
> > > > In dom0, check the files in /etc/yum.repos.d for the problem value.
> > > > Could possibly be copying them from there.
> > > > 
> > > 
> > > I removed the value it's complaining about (failovermethod=priority). And
> > > nothing changed, the same error. Everytime when I save and try update 
> > > again
> > > I see this 'failovermethod=priority' in the file 'yum.repos.d'.
> > > 
> > > So I tried the fresh sys-firewall and tried to change UpdateVM on sys-net
> > > and nothing changed :(
> > > 
> > 
> > Then you simply have not deleted the entry from every file in dom0.
> > 
> > In any case it's a warning and harmless. Also a fix is in the pipeline.
> > It's always good practive to check that your problem isnt already covered
> > - it **has** been covered here the Forum, and also at github in the
> > issue tracker - #6581, and comes up with a trivial search.
> 
> After reading this, I tried to find the issue, starting at the Qubes OS main
> page. Unfortunately you'll have to follow several links starting from the
> "Team" link until you get there.

I wouldn't start from there.

ddg "qubes issues failovermethod" takes me straight to it, as does
"failovermethod=priority error".

"failovermethod=priority" takes you directly to the Red Hat bugzilla
where the issue is discussed and resolved.


> 
> I wonder:
> * Is it possible to add some more direct links for "Search known issues"?
> * Maybe also add shortcuts for "Issues recently reported", "Issues recently
> fixed", and maybe "'popular' issues" (like those being opened many times;
> unsure if that's possible)
> 

Where do you think these links would be helpful?

-- 
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/20210526144037.GA16045%40thirdeyesecurity.org.


Re: [qubes-users] Salting your Qubes

2021-05-26 Thread unman
On Tue, May 25, 2021 at 08:25:41PM +, pillule wrote:
> 
> pillule  writes:
> 
> > Hi unman.
> > 
> > I am learning to "salting my Qubes", what decided me is your recipe for
> > apt-cacher-ng (sometimes my bandwith really matters).
> > 
> > So far I get some things working such as an automated
> > template/templateDispVM/staticDispVM for firefox and its configuration
> > with some
> > extensions.
> > 
> > So with a little more confidence, right now I am installing your
> > apt-cacher-ng
> > recipe.
> > 
> > I read from the docs of apt-cacher-ng :
> > "6.3 Fedora Core
> > Attempts to add apt-cacher-ng support ended up in pain and the author
> > lost any
> > motivation in further research on this subject. "
> > 
> > Do you get it working ?
> > 
> > In all cases, can you explicit how you use apt-cacher-ng only for debian
> > derivatives? The RPC policy you provided will apply to all templates,
> > and calls
> > to https from fedora will be denied, preventing them to update ; or I am
> > missing something ?
> > 
> > > Happy to take suggestions for other configurations, or features.
> > > 
> > > unman
> > 
> > Sometimes ago you mentioned on the mailing list to use snort and
> > tripwire.
> > I don't know if it is trivial to deploy but that is surely one of the
> > next
> > things I will look at.
> 
> I have been fooled by :
> https://github.com/QubesOS/qubes-issues/issues/6585
> 
> Actually my apt-cacher-ng is also denying qubes updates :
> 
> Hit:1 http://HTTPS///deb.debian.org/debian buster InRelease
> Hit:2 http://HTTPS///deb.debian.org/debian-security buster/updates InRelease
> Err:3 http://HTTPS///deb.qubes-os.org/r4.0/vm buster InRelease
>  Connection failed [IP: 127.0.0.1 8082]
> Err:4 http://HTTPS///deb.qubes-os.org/r4.0/vm buster-testing InRelease
>  Connection failed [IP: 127.0.0.1 8082]
> Reading package lists...
> Building dependency tree...
> Reading state information...
> All packages are up to date.
> W: Failed to fetch
> http://HTTPS///deb.qubes-os.org/r4.0/vm/dists/buster/InRelease Connection
> failed [IP: 127.0.0.1 8082]
> W: Failed to fetch
> http://HTTPS///deb.qubes-os.org/r4.0/vm/dists/buster-testing/InRelease
> Connection failed [IP: 127.0.0.1 8082]
> W: Some index files failed to download. They have been ignored, or old ones
> used instead.
> 
> 
> 
The repository was unavailable for a while. Was that the issue?

-- 
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/20210526133016.GF15406%40thirdeyesecurity.org.


Re: [qubes-users] Salting your Qubes

2021-05-26 Thread unman
On Tue, May 25, 2021 at 07:05:40PM +, pillule wrote:
> 
> Hi unman.
> 
> I am learning to "salting my Qubes", what decided me is your recipe for
> apt-cacher-ng (sometimes my bandwith really matters).
> 
> So far I get some things working such as an automated
> template/templateDispVM/staticDispVM for firefox and its configuration with
> some
> extensions.
> 
> So with a little more confidence, right now I am installing your
> apt-cacher-ng
> recipe.
> 
> I read from the docs of apt-cacher-ng :
> "6.3 Fedora Core
> Attempts to add apt-cacher-ng support ended up in pain and the author lost
> any
> motivation in further research on this subject. "
> 
> Do you get it working ?

Yes, apt-cacher-ng  works for Fedora updates.

You have to make some changes - 
First, on the client side, comment out "metalink" lines, and uncomment
"baseurl" lines. This is because the metalink will keep loading new
https:// repositories, and apt-cacher-ng cant cache those requests,
as you know.
Second, watch the caches in /var/cache/apt-cacher-ng , and add any new
ones to the fedora_mirrors file - this is because that file doesn't
contain all Fedora repositories.

After a while you will have almost all your Fedora updates cached, and
will see the speed increase.

-- 
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/20210526132914.GE15406%40thirdeyesecurity.org.


Re: [qubes-users] bug ?

2021-05-17 Thread unman
On Mon, May 17, 2021 at 03:16:10PM +0200, haaber wrote:
> Hello, I followed a link in my mailVM-thunderbird, which configured to
> open links inside a new tempVM. When I reboot the parent mailVM, the
> child-disp-VM dies with it. This is not what I expected.
> 
> Is it some wanted behaviour or a bug? Cheers
> 

It is, I think, wanted, but not by you.
Because the disposableVM was spawned from the parent, it is reaped when
the parent dies.
To keep the disposableVM runninng you would need to create it from dom0
and then "qvm-open" to that disposableVM .

-- 
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/20210517132456.GA30032%40thirdeyesecurity.org.


Re: [qubes-users] Re: recreate firewall qube

2021-05-17 Thread unman
I'm not familiar with that script but you **should** be able to rerun it
without harm.
(It should have been written to allow you to do this.)

-- 
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/20210517120916.GB29379%40thirdeyesecurity.org.


Re: [qubes-users] Re: recreate firewall qube

2021-05-14 Thread unman
On Fri, May 14, 2021 at 03:55:50PM +0100, lik...@gmx.de wrote:
> 
> > With salt? `qubesctl state.apply qvm.sys-firewall` should do it.
> >
> > But sys-firewall is just a qube with networking enabled, "provides-network" 
> > set to True and
> > memory 500.
> >
> 
> Ok, maybe there's another issue. Currently I'm not able to expose a port to 
> outside world (outside my qubes box) which was working 1/2 year ago but now 
> it doesn't:
> I've tried these scripts to do it:
> - https://github.com/QubesOS/qubes-issues/issues/5693
>   (https://gist.github.com/fepitre/941d7161ae1150d90e15f778027e3248)
> - https://github.com/QubesOS/qubes-issues/issues/4028
>   (https://github.com/niccokunzmann/qvm-expose-port)
> - https://gist.github.com/jpouellet/d8cd0eb8589a5b9bf0c53a28fc530369
> 
> In my vm-to-be-exposed I used besides the service I actually want to expose 
> the following:
> - python3 -m http.server
> - netcat -lv port
> 
> Connections in my local network to this AppVM using the IP of my qubes-NetVM 
> all fail with a timeout. If I'm trying to connect from my qubes box to a 
> simple ubuntu with an exposed port it works.
> 
> That's why my hypothesis was that I messed up my firewall qube.
> 
> Any ides how I could tackle down the problem?
> 

Have you read https://www.qubes-os.org/doc/firewall ?
What templates are you using for sys-net and sys-firewall?

Start at sys-net - you should have a rule directing inbound traffic to
 to sys-firewall.
Open a terminal in sys-net, and observe the counters in PRE-ROUTING and
FORWARD.
Attempt to make a connection - the counters should increment.

Do the same in sys-firewall.
Again, when you try to make a connection, you should see the counters
increment.

Do the same in the target qube. Here you should see the counter
increment in the filter chain.

Stepping down the network chain like this will help you identify where
your problem lies.

-- 
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/20210514150854.GA15606%40thirdeyesecurity.org.


Re: [qubes-users] recreate firewall qube

2021-05-14 Thread unman
On Fri, May 14, 2021 at 03:02:59PM +0100, lik...@gmx.de wrote:
> Hi,
> 
> in case I messed up my firewall qube:
> 
> 1. What's the best way to re-create it with default settings?
> 2. Since 7 months saltstack states for sys-* were updated to support 
> disposable sys-*: 
> https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/sys-firewall.sls
> ?? a) is this part of v4.0.4?
> ?? b) how could I use it if it's part of v4.0.4?
> 
> Thanks in advance!
> P.
> 

With salt? `qubesctl state.apply qvm.sys-firewall` should do it.

But sys-firewall is just a qube with networking enabled, "provides-network" set 
to True and
memory 500.

The states for disposable sys-* are in master, not in the 4.0 branch, so
not part of 4.0.4. No reason why you couldnt try backporting it into a
4.0


-- 
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/20210514142923.GE14880%40thirdeyesecurity.org.


Re: [qubes-users] Dom0 update error (Converting database from bdb to sqlite backend)

2021-05-14 Thread unman
On Fri, May 14, 2021 at 05:30:30AM -0700, load...@gmail.com wrote:
> On Wednesday, May 12, 2021 at 10:00:16 PM UTC+3 awokd wrote:
> 
> > load...@gmail.com: 
> > > On Monday, May 10, 2021 at 10:06:10 PM UTC+3 awokd wrote: 
> >
> >
> > In dom0, check the files in /etc/yum.repos.d for the problem value. 
> > Could possibly be copying them from there. 
> >
> 
> I removed the value it's complaining about (failovermethod=priority). And 
> nothing changed, the same error. Everytime when I save and try update again 
> I see this 'failovermethod=priority' in the file 'yum.repos.d'.
> 
> So I tried the fresh sys-firewall and tried to change UpdateVM on sys-net 
> and nothing changed :(
> 

Then you simply have not deleted the entry from every file in dom0.

In any case it's a warning and harmless. Also a fix is in the pipeline.
It's always good practive to check that your problem isnt already covered
- it **has** been covered here the Forum, and also at github in the
issue tracker - #6581, and comes up with a trivial search.

-- 
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/20210514132200.GA14880%40thirdeyesecurity.org.


Re: [qubes-users] How do I install trezor-bridge on a Qubes system without a sys-usb qube e

2021-05-13 Thread unman
On Wed, May 12, 2021 at 07:02:36PM +, 'awokd' via qubes-users wrote:
> unman:
> 
> > Is it unusual to have more than one controller on a laptop? Venerable
> > old Thinkpads had 2 or 3, and you could easily keep one for dom0 and the
> > other(s) for sys-usb purposes.
> 
> From what I hear/have seen, newer laptops often only have one, in the
> continued pursuit of saving a few pennies at the customer's expense. Maybe
> I've only heard of them because of that issue, however.
> 

Thanks. Always done at the customer's expense, as you say.

-- 
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/20210513143001.GA9884%40thirdeyesecurity.org.


Re: [qubes-users] DNS issues: servfail on selected subdomains, Qubes modifying DNS replies by stripping IPv6?

2021-05-12 Thread unman
On Tue, May 11, 2021 at 11:47:50PM +0200, 'qtpie' via qubes-users wrote:
> I have a very annoying issue with DNS recently. I'm using the standard DNS
> device and servers provided by my internetprovider which runs a full
> dual-stack IPv4/6. Other non-qubes devices have no issues. I think this
> might be a Qubes bug but I want to ask for help first to rule out an error
> on my side.
> 
> Selected domainnames (all subdomains, eg www.qubes.org, so not qubes.org)
> get a SERVFAIL when trying to resolve them within applications, and on the
> commandline with 'host' and 'nslookup'. Strangely enough, 'dig' has no
> issues, (querying the same default resolver ip of course). At times, the
> domainname will resolve inside sys-net and certain app-vm's, and not in
> another app-vm. At other times, it resolves nowhere. When quering resolvers
> directly (like my isp's resolvers or 1.1.1.1) the issue does not occur.
> 
> What can be happening here? One of the only consistent hints I found is that
> Qubes does not seem to pass the full nslookup response from sys-net to the
> appvm (compare nslookup examples below). My router gives a servfail when
> quering it via ipv4, nslookup then tries it's ipv6 address, where it does
> get a reply, but this reply is not passed to the appvm. The servfail might
> be an ipv6 issue or an issue with my router, but I think still Qubes should
> pass the full response, right?
> 

Do you have ipv6 enabled across every part of the Qubes networking
chain?

Just to be clear - this is an intermittent issue, intermittent in time
and as it affects qubes?
The fact that dig has no issues is interesting - can you test dig with
IPv4 and IPv6 separately?
Do you see the same behaviour if you set the resolver in sys-net to use
9.9.9.9?

-- 
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/20210512131540.GA3746%40thirdeyesecurity.org.


Re: [qubes-users] How do I install trezor-bridge on a Qubes system without a sys-usb qube e

2021-05-11 Thread unman
On Mon, May 10, 2021 at 06:12:47PM +, 'awokd' via qubes-users wrote:
> 'Joanna Anders' via qubes-users:
> > 
> > I'm trying to make Trezor Model T work on my Qubes system installed on a
> > ssd *usb drive* according to this guide https://wiki.trezor.io/Qubes_OS .
> > So by default the *sys-usb qube is disabled*. If I try to enable it my
> > whole system turns unusable.
> > 
> > Should I edit the *sys-net* qube instead of nonexistent *sys-usb* ?
> > 
> If I'm not mistaken, running Qubes directly from a USB drive requires dom0
> to own at least the USB controller responsible for the drive. This would
> mean you would have to run the trezor service there as well, but as dom0's
> networking is disabled, wouldn't get you any further. Unfortunately, think
> you pretty much require a sys-usb. If you have more than one controller
> driving the external ports (fairly unusual on laptops, though) you may be
> able to assign a single unused controller to a sys-usb qube and use the
> Trezor device on those specific ports. Not an option if your drive is on one
> of the same ports. Other option could be to install Qubes on local disk
> instead of USB.
> 

Is it unusual to have more than one controller on a laptop? Venerable
old Thinkpads had 2 or 3, and you could easily keep one for dom0 and the
other(s) for sys-usb purposes.
But you're not mistaken - if you only have 1 controller, you cant
allocate that to a sys-usb while running from usb.

-- 
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/20210511144629.GA30353%40thirdeyesecurity.org.


Re: [qubes-users] Fedora Process didn't actually upgrade the Fedora version

2021-05-08 Thread unman
On Sat, May 08, 2021 at 03:30:57AM -0700, Patrick wrote:
> Hi, I am trying to upgrade Fedora 30 to Fedora 33. I followed instructions 
> here: https://www.qubes-os.org/doc/template/fedora/upgrade/
> 
> The actual upgrade command shown there is:
> sudo dnf --releasever= distro-sync --best --allowerasing
> 
> In my case (in the VM Template to be upgraded):
> sudo dnf --releasever=33 distro-sync -best -allowerasing
> 
> It does a major upgrade, 1200 or so instructions, and is successful. 
> However, when I check the version it is still Fedora version 30. 
> 
> Any help there?
> 
> Thanks,
> Patrick
> Dallas
> 

Interesting.
I'm not convinced there is an upgrade path direct from 30 to 33 - best
practice usually suggests that you take all the intermediate steps -
30->31, 31->32, 32->33
I don't know if this accounts for the issue.

On the other hand, (and from what you say) this could be completely
cosmetic. You could just edit /etc/fedora-release to show 33.
I've just skipped from 31-33, and the upgrade performed properly, and
the release number changed to 33.

Just to check, you did install the upgraded fedora PGP key? If you didn't
then the packages would all be downloaded, but *not* installed.

-- 
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/20210508143707.GA14128%40thirdeyesecurity.org.


Re: [qubes-users] Disposable VMs starting with a QubesIncoming folder

2021-05-01 Thread unman
On Sat, May 01, 2021 at 01:35:55PM -0700, TheGardner wrote:
> Thanks for the help, but a start of the template wouldn't help, cause the 
> /QubesIncoming folder wasn't build there. It was build in a dvm-VM.
> But found a way now. You have to start the dvm-VM via Qubes Manager and 
> have to start a terminal via rightclick on the Q symbol in the info bar > 
> dvm-Qube > Run Terminal.
> 
> David Hobach schrieb am Samstag, 1. Mai 2021 um 13:43:56 UTC+2:
> 
> >
> > Just start the template VM and remove the ~/QubesIncoming folder. 
> >
> >
> 

DisposableVMs effectively have **two** templates.
There is the qube that is the template for the disposableVM - that is a
qube that has the `template_for_dispvms` property set. This is called
the DisposableVM Template.
Then there is the "normal" Template that *that* qube uses.

I think that David was suggesting you edit the qube that the
disposableVM is based on this is what you did.

-- 
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/20210502022348.GA10288%40thirdeyesecurity.org.


Re: [qubes-users] Partitioning of the Qubes-R4.0.4 ISO

2021-04-13 Thread unman
On Tue, Apr 13, 2021 at 08:19:13AM +0200, Ulrich Windl wrote:
> Hi!
> 
> I put the Qubes-R4.0.4 ISO on a memory card (it boots). However when I 
> inspect the partitions, I'm quite surprised:
> # fdisk -l /dev/sdg
> Disk /dev/sdg: 7.4 GiB, 7969177600 bytes, 15564800 sectors
> Disk model: STORAGE DEVICE  
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x501be065
> Device Boot Start  End  Sectors  Size Id Type
> /dev/sdg1  *0 10156031 10156032  4.9G  0 Empty
> /dev/sdg210286137560348 29.5M ef EFI (FAT-12/16/32)
> 
> So the EFI partition is not marked bootable (active), and it overlaps the 
> other partition?
> I wouldn't be surprised if some BIOS complained...
> 
> I see other images also don't mark the EFI as bootable, but they don't use 
> overlapping partitions.
> 
> Regards,
> Ulrich
> 
> 
> 

It's not unusual:

ubuntu20.04.2.0-desktop-amd64.iso
Device Boot Start  End  Sectors  Size Id Type
/dev/sdg1  *0  5619583  5619584  2.7G  0 Empty
/dev/sdg21700 9699 8000  3.9M ef EFI (FAT-12/16/32)


debian-10.8.0-amd64-DVD-1.iso
Device Boot Start  End  Sectors  Size Id Type
/dev/sdg1  *0  7750847  7750848  3.7G  0 Empty
/dev/sdg2   2376429427 5664  2.8M ef EFI (FAT-12/16/32)

-- 
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/20210413170037.GA21677%40thirdeyesecurity.org.


Re: [qubes-users] X230 - external monitor how to

2021-04-08 Thread unman
On Thu, Apr 08, 2021 at 01:25:57PM +, 'taran1s' via qubes-users wrote:
> 
> 
> unman:
> > On Wed, Apr 07, 2021 at 01:59:10PM +, 'taran1s' via qubes-users wrote:
> > > How do I use the X230+Qubes 4.0 with external monitor of at least 1080p or
> > > higher? I understand that a dock station (Ultrabase?) is required to be 
> > > able
> > > to use the HiDPI external monitor with X230.
> > > 
> > > What smallest dock station would you propose for this purpose? Is there
> > > possibly some other, more portable way, to get X230 to use HiDPI external
> > > monitor?
> > > 
> > 
> > You don't need a dock for this - the x230 supports 1920x1200 through HDMI
> > and 2560x1600 through the DisplayPort.
> > Of course, a dock is always nice.
> 
> This is really interesting and thank you a tone for this information. I dont
> see the HDMI output from my X230 but there seem to be a Mini Displayport.
> Very nice.
> 
> > 
> > You can also mod the x230 with a board and updated panel to get 1080p on
> > a larger IPS panel - very portable and a real boost to the x230.
> 
> Can you please elaborate more on this? What kind of board and updated panel
> is it? I didn't know that X230 can be modded to have 1080p IPS display at
> all. This would possibly solve most need to have external display for simple
> media.
> 

There are a number of boards you can use - imo the best is from
nitrocaster  - nitrocaster.me/store
They all work in the same way - you solder the board on the motherboard
and "steal" output from the dock. With some minor modification to the
screen enclosure you can fit a really nice 1080p IPS panel to the x230.

There are a number of people who will do this for you, if you doubt
your soldering skills. If you didnt already have an x230 you can also buy
x230 premodded, but that's no use to you. :-(

-- 
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/20210408142556.GA26392%40thirdeyesecurity.org.


Re: [qubes-users] X230 - external monitor how to

2021-04-07 Thread unman
On Wed, Apr 07, 2021 at 01:59:10PM +, 'taran1s' via qubes-users wrote:
> How do I use the X230+Qubes 4.0 with external monitor of at least 1080p or
> higher? I understand that a dock station (Ultrabase?) is required to be able
> to use the HiDPI external monitor with X230.
> 
> What smallest dock station would you propose for this purpose? Is there
> possibly some other, more portable way, to get X230 to use HiDPI external
> monitor?
> 

You don't need a dock for this - the x230 supports 1920x1200 through HDMI
and 2560x1600 through the DisplayPort.
Of course, a dock is always nice.

You can also mod the x230 with a board and updated panel to get 1080p on
a larger IPS panel - very portable and a real boost to the x230.

-- 
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/20210408004625.GB23013%40thirdeyesecurity.org.


Re: [qubes-users] X230 - switch-on backlit keyboard

2021-04-06 Thread unman
On Tue, Apr 06, 2021 at 03:32:56PM +, 'taran1s' via qubes-users wrote:
> 
> 
> unman:
> > On Tue, Apr 06, 2021 at 12:44:31PM +, 'taran1s' via qubes-users wrote:
> > > I have got my X230 with Qubes preinstalled. Everything seems to work well,
> > > but I cant switch-on the backlit keyboard. Pressing Fn+Space just cycles
> > > between ON and OFF of the upper light (besides camera). The X230 of course
> > > has, or should have, the backlit keyboard.
> > > 
> > > I didn't find any options in the Qubes Settings Manager to make it run. 
> > > How
> > > can I make it run?
> > > 
> > > Thank you!
> > > 
> > 
> > This isn't a Qubes issue, because the backlit keyboard works fine on
> > varieties of 4.
> > Just to check - you **do** have a backlit keyboard? When you look at the
> > lamp icon on the space bar, are the beams pointing to the screen or
> > toward you?
> > 
> 
> Ah I see. The beams pointing towards me.
> 

Regrettably you do not have a back lit keyboard.

-- 
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/20210406161557.GA15745%40thirdeyesecurity.org.


Re: [qubes-users] X230 - switch-on backlit keyboard

2021-04-06 Thread unman
On Tue, Apr 06, 2021 at 12:44:31PM +, 'taran1s' via qubes-users wrote:
> I have got my X230 with Qubes preinstalled. Everything seems to work well,
> but I cant switch-on the backlit keyboard. Pressing Fn+Space just cycles
> between ON and OFF of the upper light (besides camera). The X230 of course
> has, or should have, the backlit keyboard.
> 
> I didn't find any options in the Qubes Settings Manager to make it run. How
> can I make it run?
> 
> Thank you!
> 

This isn't a Qubes issue, because the backlit keyboard works fine on
varieties of 4.
Just to check - you **do** have a backlit keyboard? When you look at the
lamp icon on the space bar, are the beams pointing to the screen or
toward you?

-- 
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/20210406150727.GA15347%40thirdeyesecurity.org.


Re: [qubes-users] Management of salt configs: Syncing from dom0 to a git-repository harboring vm?

2021-04-05 Thread unman
On Sun, Apr 04, 2021 at 03:01:52PM +0100, unman wrote:
> On Sat, Apr 03, 2021 at 10:45:59AM -0700, balin wrote:
> > I see. that seems straight forward then ... how time consuming is such a 
> > move?
> > 
> > Sincerely, Joh
> > 
> > On Saturday, April 3, 2021 at 7:36:02 PM UTC+2 unman wrote:
> > 
> > > On Sat, Apr 03, 2021 at 09:42:49AM -0700, balin wrote:
> > > > Hi,
> > > > I urgently need to backup (and version control) my by now relative 
> > > > elaborate salt config.
> > > > 
> > > > The plan is to manage it in a `git` repo in a dedicated Vm (whether I 
> > > push 
> > > > it to some private online repo still needs some contemplation).
> > > > A shell script will
> > > > a) copy/sync the salt dir to the `git` vm
> > > > b) execute git add/commit(and possibly push) there
> > > > 
> > > > >From this proposition the need arises to sync an entire directory from 
> > > > `dom0` to the `git` vm. I found 
> > > > `https://www.qubes-os.org/doc/copy-from-dom0/` 
> > > <https://www.qubes-os.org/doc/copy-from-dom0/> and consequently 
> > > `qvm-copy-to-vm 
> > > >  ` ...
> > > > I can see a workflow of packing the salt dir to a *.zip or some such, 
> > > > copying that, unpacking it on the `git` vm through `qrexec` and 
> > > preoceeding 
> > > > with git operations ... somewhat inelegant.
> > > > Is there any other means of syncing an entire directory tree from 
> > > > `dom0` 
> > > to 
> > > > a vm?
> > > > 
> > > > Thanks for any pointers.
> > > > 
> > > > Sincerely, Joh
> > > > 
> > >
> > > qvm-copy-to-vm will take a directory as an argument.
> > > You will have to then sync the files from QubesIncoming/dom0 to your git
> > > repo, but that is trivial.
> > >
> 
> Not at all time consuming.
> A simple script in dom0 to :
> qvm-copy-to-vm
> copy in the qube
> git push in the qube
> 
> I have something you could look at - I'll post it in the morning.
> 

Something like:
```
#!/usr/bin/bash
qvm-copy-to-vm $1 $2
qvm-run $2 'mv /home/user/QubesIncoming/dom0/$1/* '
qvm-run $2 'rm -rf /home/user/QubesIncoming/dom0/$1 '
```
in dom0.

Depending on how you have configured git access you may also be able to
commit and push as part of the same script. Without knowing your
configuration I suspect that the rest wont be helpful.
(Hint - just try at the coommand line in dom0 - get it working and then
add to the script.)

-- 
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/20210405141651.GB9457%40thirdeyesecurity.org.


Re: [qubes-users] Management of salt configs: Syncing from dom0 to a git-repository harboring vm?

2021-04-04 Thread unman
On Sat, Apr 03, 2021 at 10:45:59AM -0700, balin wrote:
> I see. that seems straight forward then ... how time consuming is such a 
> move?
> 
> Sincerely, Joh
> 
> On Saturday, April 3, 2021 at 7:36:02 PM UTC+2 unman wrote:
> 
> > On Sat, Apr 03, 2021 at 09:42:49AM -0700, balin wrote:
> > > Hi,
> > > I urgently need to backup (and version control) my by now relative 
> > > elaborate salt config.
> > > 
> > > The plan is to manage it in a `git` repo in a dedicated Vm (whether I 
> > push 
> > > it to some private online repo still needs some contemplation).
> > > A shell script will
> > > a) copy/sync the salt dir to the `git` vm
> > > b) execute git add/commit(and possibly push) there
> > > 
> > > >From this proposition the need arises to sync an entire directory from 
> > > `dom0` to the `git` vm. I found 
> > > `https://www.qubes-os.org/doc/copy-from-dom0/` 
> > <https://www.qubes-os.org/doc/copy-from-dom0/> and consequently 
> > `qvm-copy-to-vm 
> > >  ` ...
> > > I can see a workflow of packing the salt dir to a *.zip or some such, 
> > > copying that, unpacking it on the `git` vm through `qrexec` and 
> > preoceeding 
> > > with git operations ... somewhat inelegant.
> > > Is there any other means of syncing an entire directory tree from `dom0` 
> > to 
> > > a vm?
> > > 
> > > Thanks for any pointers.
> > > 
> > > Sincerely, Joh
> > > 
> >
> > qvm-copy-to-vm will take a directory as an argument.
> > You will have to then sync the files from QubesIncoming/dom0 to your git
> > repo, but that is trivial.
> >

Not at all time consuming.
A simple script in dom0 to :
qvm-copy-to-vm
copy in the qube
git push in the qube

I have something you could look at - I'll post it in the morning.

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


Re: [qubes-users] Management of salt configs: Syncing from dom0 to a git-repository harboring vm?

2021-04-03 Thread unman
On Sat, Apr 03, 2021 at 09:42:49AM -0700, balin wrote:
> Hi,
> I urgently need to backup (and version control) my by now relative 
> elaborate salt config.
> 
> The plan is to manage it in a `git` repo in a dedicated Vm (whether I push 
> it to some private online repo still needs some contemplation).
> A shell script will
> a) copy/sync the salt dir to the `git` vm
> b) execute git add/commit(and possibly push) there
> 
> >From this proposition the need arises to sync an entire directory from 
> `dom0` to the `git` vm. I found 
> `https://www.qubes-os.org/doc/copy-from-dom0/` and consequently 
> `qvm-copy-to-vm 
>  ` ...
> I can see a workflow of packing the salt dir to a *.zip or some such, 
> copying that, unpacking it on the `git` vm through `qrexec` and preoceeding 
> with git operations ... somewhat inelegant.
> Is there any other means of syncing an entire directory tree from `dom0` to 
> a vm?
> 
> Thanks for any pointers.
> 
> Sincerely, Joh
> 

qvm-copy-to-vm will take a directory as an argument.
You will have to then sync the files from QubesIncoming/dom0 to your git
repo, but that is trivial.

-- 
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/20210403173559.GE32370%40thirdeyesecurity.org.


Re: [qubes-users] Re: cannot verify signatures R4.0.4

2021-03-27 Thread unman
On Fri, Mar 26, 2021 at 09:39:39PM -0700, Andrew David Wong wrote:
> > So perhaps it may be more appropriate to add to the detached file also the
> > wording "use this file to follow the Qubes verification tutorial"
> 
> Sure, if it's possible to include extra comment text that doesn't interfere
> with the signature, it wouldn't hurt to point to the guide. I'll ask the
> team about this.
> 

Yes, you can add a comment, or multiple comments using the handy
`--comment ` parameter.
Whether someone who wont read the detailed guides, even after hitting
problems, will check inside the signature file is a moot point.
And in the present case, it isn't clear that the user downloaded the sig
file but didn't use it.

-- 
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/20210327164639.GE26996%40thirdeyesecurity.org.


Re: [qubes-users] Memory issue

2021-03-12 Thread unman
On Fri, Mar 12, 2021 at 08:10:42PM +, thefifthseason via qubes-users wrote:
> 
> 
>The quick: 
> 
>Dom0 Task Manager shows memory usage percent as always increasing.
> Closing Virtual Machines does not seem to free up any memory by
> displayed memory usage percent. 
> 
>The questions: 
> 
>Are there any advice on what I should do with this situation?Should
> I clean out Qubes memory buffer/catch? If so, what safe command should
> be used?Or, if that isn???t the issue, what should I look for? What
> more information do you good elves need to help the issue? 
> 
>The slow: 
> 
>I noticed this situation a good week ago when I looked at Dom0 task
> manager. It showed my memory usage to be around 95%, that is a lot.
> The computers total memory capacity is 32gig. My normal memory usage
> tend to be around 35-40%, a fairly steady level measured over long
> time. After seeing my memory maxing out I attempted to close down one
> virtual machine after the other, but it did not appear to make any
> difference in terms of freeing up memory. So I decided to restart my
> computer and that made everything back to normal???for a little while.
> Starting my normal virtual machines and got to the normal memory usage
> level. But then it just kept adding on, a disposable machine opened
> and closed and the memory usage increased, another virtual machine
> opened and the memory increased, closing it did not affect the memory
> level. And so it kept adding on more and more memory usage as I did my
> normal computing things like browsing and so on. In writing moment
> I???ve reached 93% of memory capacity.   
> 
>The extra: 
> 
>Please, treat me as a newbie. Although I???ve been using Qubes OS
> for several years (its pretty cool operating system, thank you
> creators and maintainers 
> 

I'm not sure what "Dom0 task manager" is, and what it shows.
But the memory allocated to dom0 is only *part* of the available
memory, and can be constrained further using boot parameters :
dom0_mem=max:...

The memory allocated to Virtual machines is from a separate pool - this
is why closing qubes does not free up memory in dom0.
Of your 32GB, the default would be to have 4GB allocated to dom0 (this
can easily be reduced to 2048 or 1536), with the balance of 28GB pooled
between the open qubes.

I'm not sure why you are now seeing dom0 usage up from previous levels
-unless you can associate this with difficulties in running Qubes I
wouldnt worry about some notional 95% figure.

It's possible I am misinterpreting your mail. If so, perhaps you could
explain exactly what effect this has on your Qubes experience.

-- 
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/20210313012149.GA11133%40thirdeyesecurity.org.


Re: [qubes-users] Re: qrexec_timeout does not truly accept 360

2021-03-10 Thread unman
On Wed, Mar 10, 2021 at 04:20:57PM -0800, Rob Townley wrote:
> Replying directly here in Google Groups because could not find this post in 
> email.
> 
> Where does one find the idleness monitor setting?
> 
> [root@dom0 ~]# qvm-prefs --verbose vmName | egrep -i shut
> shutdown_timeoutD  60
> [root@dom0 ~]# qvm-prefs --verbose vmName | egrep -i idle
> [root@dom0 ~]# 
> 
> 

You should be able to see if it is set with qvm-features, or
qvm-service.
It is called (in Debian) shutdown-idle service

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


Re: [qubes-users] maybe is root issue?

2021-03-07 Thread unman
On Sun, Mar 07, 2021 at 04:41:54AM -0800, unun wong wrote:
> hi ervery, 
> when I try to run qvm in dom0 terminal, command is not find, and I try to 
> creat new file in the /etc/NetworkManager/conf.d/ , access also denied. I 
> wonder is my user do not have the authority?
> 

There are *many* qvm- commands in dom0 - type qvm and then TAB to see
them.
The one you will use most often is qvm-run
To edit config files you will want to use `sudo` or`sudo su -` to get root.

-- 
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/20210307142746.GD14041%40thirdeyesecurity.org.


Re: [qubes-users] Re: [QubesOS/qubes-issues] Improve Clipboard Experience (#5778)

2021-03-07 Thread unman
On Sat, Mar 06, 2021 at 01:16:45AM +0100, donoban wrote:
> Well, since the issue was finally closed I will reply here.
> 
> On 3/6/21 1:39 AM, unman wrote:
> > I don't understand this example - if the destination is compromised, then
> > why would there be a need to modify the clipboard? They just capture the
> > data as is and exfiltrate it - you are hosed, and the Qubes clipboard is
> > the least of your problems.
> 
> At destination there is nothing useful to steal (at least not bitcoins)
> the bitcoin address is not useful for the attacker, it is a public
> address and private keys are in other uncompromised offline vm.
> 
> What the attacker tries to do is replace your address in the clipboard
> to other address (controlled by him), in the hope that you paste it to
> someone who wants to send funds for you.
> 
> I'm agree that the attacker could do a lot of additional things but many
> of them are more difficult, prone to fail, prone to cause detection. So
> I don't think it is a justification for not having a more secure
> clipboard and also easier to use which was the main objective.
> 

Again, I don't understand your example. You say, "At destination there is
nothing useful to steal", and then you exactly indicate what is useful
to steal, i.e the bitcoin address.

In any case, this is where we disagree.
Most of those "additional things" seem to me to be far easier to
implement, and have far wider application, than an attack on the Qubes
clipboard.
I haven't seen anything in the discussion on GitHub which would provide 
"a more secure clipboard", and which would be "easier to use". I think
what is needed are some concrete proposals, and perhaps poc -then
we'd actually have something to consider. Until I see that I'm bowing
out.

-- 
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/20210307141431.GA14041%40thirdeyesecurity.org.


Re: [qubes-users] Open sourcing my salt configs

2021-03-04 Thread unman
On Wed, Mar 03, 2021 at 11:58:41AM +, 'keyandthegate' via qubes-users wrote:
> I've been developing a lot of salt config for myself and I want to start open 
> sourcing it so that I can:
> 
> - Ask for public security review
> - Accept patches
> - Help people use Qubes a little better, when I think Qubes supports 
> anarchistic praxis and is a force of good in the world
> 
> I'm worried about the following things:
> 
> - I lose my security through obscurity, which I don't want to do without the 
> help of at least one non-amateur code reviewer for anything I publish
> 
> - (and I'm not sure if the economics/incentives work out here such that I 
> should be paying someone to help me with this or not)
> - I don't want to publish anything security sensitive without code review 
> because I don't want to harm people
> 
> Additionally, I'm not sure how to package salt config via a .deb package. Are 
> there any existing examples of this?
> 
> As an example of what I want to publish, I've written some config to create a 
> private debian package repo vm powered by a YAML file that lets you specify 
> sources to download packages (e.g. that are hosted as github releases) and 
> verify them via gpg, then provide them to vms. My motivation is towards the 
> goal of being able to destroy and recreate my templates from salt at any 
> time, because salt is not stateless (unlike e.g. nix or bazel), e.g. if you 
> decide to no longer add a package repo, you have to manually remove it from 
> the domain in addition to updating the salt config, and you may forget; being 
> able to recreate templates solves the otherwise almost intractable problem of 
> knowing your templates aren't out of sync; it also means you can exclude 
> templates from backups if you're brave, which can save a lot of space.
> 
> Another example of some code I may want to publish:
> (WARNING: I think this may have a critical security issue of exposing config 
> files to domains they don't belong to, but I'm not sure. Would need to 
> investigate before publishing)
> This fixes TemplateNotFound errors when you try to jinja-include another file 
> within a `file.managed` `template.jinja` file.
> 
> > # MAINTAIN: Removed when fixed: 
> > https://github.com/saltstack/salt/issues/31531
> > 'patch salt issue 31531':
> > cmd.run:
> > - name: |
> > if [[ ! -f "$XDG_DATA_HOME"/patched-salt-31531 ]]; then
> > cat < > sudo sed -i'' "s#if fn_.strip() and fn_.startswith(path):#if fn_.strip() 
> > and (fn_.startswith(path) or path == '/'):#" 
> > /usr/lib/python3/dist-packages/salt/fileclient.py && \
> > if ! grep extra-filerefs /etc/qubes-rpc/qubes.SaltLinuxVM >/dev/null; then 
> > sudo sed -i'' "s#salt-ssh#salt-ssh --extra-filerefs salt:///#" 
> > /etc/qubes-rpc/qubes.SaltLinuxVM; fi
> > CMD
> > fi
> > sudo mkdir -p "$XDG_DATA_HOME" || exit 1
> > sudo touch "$XDG_DATA_HOME"/patched-salt-31531 || exit 1
> 

Great - I love salting Qubes.
There *is* a problem in posting configs unless you are careful, but
generally this can be mitigated by making them as general as possible.
I'd be happy to take a look over what you have: you can get my email
and PGP key from the team page at Qubes.

Packaging - you need to package in an rpm because it will be handled in
dom0 (generally). I generally just package the files, and *not*
automatic execution. This is because I want people to review the files,
and possibly edit them, before executing in dom0.
If you want automatic execution, then it's simply a matter of using a
"post install" execution in the rpm. I don't like this, as stated, but
it's straightforward.

As to publishing, I have some salt on GitHub
(https://www.github.com/unman/shaker) 
Most of the states I publish are simple, in execution if not effect,
because they are teaching aids.
I have been thinking of publishing packages at https://qubes.3isec.org,
alongside the templates and Ubuntu packages that I already offer.
This could be done as an unofficial Qubes salt archive, possibly as a step
toward inclusion of packages in the official Qubes repositories.
If you'd like to take this further, drop me a line.
For general issues, reply to the list.

unman

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


Re: [qubes-users] Re: qrexec_timeout does not truly accept 360

2021-03-02 Thread unman
On Tue, Mar 02, 2021 at 03:24:31PM -0600, Rob Townley wrote:
> I really need this qube to run for over an hour without the hypervisor
> killing it.  Short of buying a much faster brand new machine, how does one
> do that?
> 
> On Mon, Mar 1, 2021 at 12:19 AM Rob Townley  wrote:
> 
> > qvm-prefs vmName qrexec_timeout 3600
> > does not return an error message.   When read, 3600 is returned.
> > However, the VM is forcibly stopped after 15 minutes.
> >
> > 1800 works
> > 2700 works
> > 3600 is not honored
> >
> > How can i get by this so this one VM can do finish its upgrade before
> > forcibly rebooted?
> >
> 

There's a confusion here - qrexec-timeout is the time to wait on boot
for the qrexec agent to be connected.
If the qube isn't booting up then you have no chance of performing an
upgrade. You should fix that problem first. BUT...
The fact that "the VM is forcibly stopped after 15 minutes" suggests to
me that you have the idleness monitor enabled, since this *does* have a
default shutdown time of 15 mins.
Can you check to see if you have the shutdown-idle service enabled this
qube?

-- 
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/20210303015840.GA8710%40thirdeyesecurity.org.


Re: [qubes-users] Re: Doing all DNS calls using DoH over Tor

2021-02-28 Thread unman
On Sun, Feb 28, 2021 at 12:37:49PM +, lik...@gmx.de wrote:
> On 8/2/20 11:46 AM, Kushal Das wrote:
> > Hi,
> > 
> > I wrote a blog post [0] explaining the steps required to move all the DNS 
> > calls
> > to any secure DoH server using Tor (to keep the calls anonymized). Here I am
> > modifying sys-firewall as the primary netwvm for the other AppVMs.
> > 
> > [0] https://kushaldas.in/posts/use-doh-over-tor-for-your-qubes-system.html
> > 
> > Kushal
> > 
> 
> Thanks Kushal!
> 
> I was using your setup successfully until changing the template from fedora 
> 32 to fedora 33. Unfortunately, I cannot figure out why it stopped working. 
> Switching back to fedora 32 works again.
> 
> Any ideas?
> 

Read the announcement about the Fedora33 template, and you'll see a
specific section on the handling of DNS, I think.

-- 
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/20210228235157.GC29492%40thirdeyesecurity.org.


Re: [qubes-users] Opening applications using qvm-run

2021-02-28 Thread unman
On Sun, Feb 28, 2021 at 12:47:39PM +, tetrahe...@danwin1210.me wrote:
> On Sat, Feb 27, 2021 at 11:57:32PM +0000, unman wrote:
> > Is this Torbrowser specific? Because it doesn't block with other
> > programs (or at least doesn't seem to do so for me).
> > On what is the "anon" qube based? How is it configured to run torbrowser
> > with no path?
> 
> It's not Torbrowser specific for me, that was just an example using a Whonix
> Workstation VM. (it does work as stated -- I did test it)
> 
> In actuality I want to launch specific applications (that launch fine using
> applications menu) from a dom0 script, but the only way I can find to launch
> them without blocking the script execution is using gnome-terminal. And that
> opens an extra (unneeded) terminal window.
> 

Do you have the same problem with non Whonix qubes?
I dont use Whonix, and dont have this problem with any of my other
template based qubes.

-- 
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/20210228234904.GA29492%40thirdeyesecurity.org.


Re: [qubes-users] Opening applications using qvm-run

2021-02-27 Thread unman
On Fri, Feb 26, 2021 at 12:01:16PM +, tetrahedra via qubes-users wrote:
> I'm trying to figure out how to open applications in VMs from dom0 using
> qvm-run, and how to do so without blocking the terminal in dom0.
> 
> For example:
> ```
> $ qvm-run anon "torbrowser qubes-os.org"
> Running 'torbrowser qubes-os.org' on anon
> 
> ```
> 
> The above command sucessfully launches Tor Browser in the `anon` VM, but I
> can't run another command in the same dom0 terminal window until Tor Browser
> (in the VM) finishes (exits).
> 
> Alternately I can do something like
> ```
> $ qvm-run anon "gnome-terminal -- torbrowser qubes-os.org"
> ```
> but that leaves a terminal window running in the `anon` VM.
> 
> I've also tried all the usual variations on `nohup`, `disown`, `&`, and the
> like, but none of them seem to do the trick.
> 
> Any ideas?
> 

Is this Torbrowser specific? Because it doesn't block with other
programs (or at least doesn't seem to do so for me).
On what is the "anon" qube based? How is it configured to run torbrowser
with no path?

-- 
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/20210227235732.GB24610%40thirdeyesecurity.org.


Re: [qubes-users] SLS update Fail

2021-02-24 Thread unman
On Mon, Feb 22, 2021 at 01:52:32PM -0800, Alexander Reseneder wrote:
> Hello qubes-users,
> 
> can someone tell me maybe what i have configured wrong or what i have to do 
> to fix that update failure?
> 
> [image: fedora_sls_update_fail.png]
> 
> Greetings
> Alex
> 

I cant see that - can you at least provide a clue as to what the
failure is?

-- 
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/20210224155202.GC5777%40thirdeyesecurity.org.


[qubes-users] Salting your Qubes

2021-02-10 Thread unman
Hi,

I'm in the process of uploading various salt configurations, which you
may find interesting.
The files are in https://github.com/unman/shaker.

There's configuration for salting various useful stuff:
A caching proxy,
A version of split-ssh,
Multiple sys-usb using various controllers (specific to x230 model),
Kali template,
A qube for building Qubes,
A qube for building/flashing coreboot,
A multimedia qube,
A file sharing qube,
Adding support for Office or Windows filesystems to templates,

with more to come.

This isn't sophisticated salt - most of these are examples from training,
and are deliberately simple. Some are old, and may need tweaking.
They are also almost all based on a debian-10-minimal template
(naturally).
Even if you have no experience with salt you should be able to read the
files and understand what they are going to do. 

I hope you use them to get started with using salt in Qubes.

I'm in the process of packaging these, and will host them at
https://qubes.3isec.org
Although it's simple to produce packages that will actually implement
the states, (as they do in initial Qubes setup), I prefer not to do
this - mainly because I think it better for users to see what's been
installed and what actions will be taken. So the packages will provide
the salt formula, for you to review, change and implement as you will.
(Change my mind if you like.)

Happy to take suggestions for other configurations, or features.

unman

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


Re: [qubes-users] blackarchlinux and kali templates do not start

2021-02-10 Thread unman
On Wed, Feb 10, 2021 at 08:30:22AM -0500, jon will wrote:
> So I was trying to make a blackarchlinux and Kali templates (because my job
> is a pen tester). I don't know why but after installing tools on
> blackarchlinux and Kali I cant start the template. When I boot it up I get
> can not connect to qrexec agent for 60 sec, see
> /var/log/xen/console/guest/guest-blackarch.log" From what I can gather it
> does not recognize the xenfs format because it says "failed to mount
> /proc/xen" when I run "sudo xl console -r blackarchlinux" in dom0. it does
> say more although that is the first error I get. kali does not have any
> error messages but still fails to boot and I get the same "cannot connect to
> qrexec agent for 60 seconds".
> 
> can anyone help?
> 
> thanks in advance.
> 

The reason for this is that these are rolling templates and the Qubes
packages cannot keep up with the changes.
Almost certainly, when you were installing the Kali packages you removed
one or more of the qubes packages.
You may be able to access a console using `sudo xl console..` in dom0,
and then see what package was removed, and restore it.
It's always best to put a hold on the qubes packages, and be prepared to
have a broken/inconsistent package system. That and periodically
snapshotting/cloning the template during build process, (and keeping
close eye on what actions will be taken) will help a great deal.

In the present case, you may be able to revert to previous state by
using `qvm-volume revert` in dom0

-- 
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/20210210142923.GA3527%40thirdeyesecurity.org.


Re: [EXT] [qubes-users] Updating a new installation

2021-02-05 Thread unman
On Thu, Feb 04, 2021 at 07:36:34PM -0800, Shawn Creighton wrote:
> 
> 
> On Thursday, February 4, 2021 at 9:52:22 PM UTC-5 Shawn Creighton wrote:
> 
> > On Tuesday, February 2, 2021 at 10:26:48 AM UTC-5 unman wrote:
> >
> >> On Mon, Feb 01, 2021 at 11:34:30PM +0100, Ulrich Windl wrote: 
> >> > On 1/27/21 7:44 AM, Shawn Creighton wrote: 
> >> > > What is the quickest and most secure way to update the entire system 
> >> > > including Dom0 on the first boot of a new install? I've noticed that 
> >> it 
> >> > > takes awhile for the updates to populate to the qubes updater when 
> >> first 
> >> > > connected to the net even though there are obviously updates 
> >> available. 
> >> > > Is there a way to expedite the process? 
> >> > 
> >> > I think you can always run the dom0 updater to get the updates, and for 
> >> the 
> >> > VMs it seems that starting one reduces the time until updates for the 
> >> > corresponding template are found. 
> >> > Still I'd like an explicit "check for updates"... 
> >> > 
> >>
> >> It's also worth checking to see what templates were installed with the 
> >> new install. 
> >> Depending on what installer you used you may find you have outdated 
> >> templates - rather than upgrading these in place it''s almost always 
> >> better to install a clean new template: 
> >> e.g. sudo qubes-dom0-update template-qubes-debian-10 
> >>
> >> As Ulrich says, starting a qube will (by default) check for updates and 
> >> report back to the system - you may or may not want this to happen 
> >> automatically - it's a service that can be disabled across the system. 
> >>
> >> You need not wait for this to happen if you use the gui updater tool - 
> >> just open the tool, select "Enable updates for qubes without known 
> >> available updates", and go ahead. 
> >> N.B Install any new templates *before* you do this. 
> >>
> >> unman 
> >>
> >
> > So  "sudo qubes-dom0-update template-qubes-debian-10" installs a new fully 
> > updated Debian 10 template? Why is it better than updating the default 
> > templates?
> >
> > Is it best to do all updating via Dom0? 
> >
> > Thanks
> >
> 
> Also does the baremetal hypervisor ever need to be updated from a default 
> install of the newest version of Qubes? I am using a Purism Librem 15v4 
> laptop. 
> 

Just updating dom0 using the tool or qubes-dom0-update is fine.

-- 
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/20210205144821.GB30766%40thirdeyesecurity.org.


Re: [EXT] [qubes-users] Updating a new installation

2021-02-05 Thread unman
> 
> 
> On Tuesday, February 2, 2021 at 10:26:48 AM UTC-5 unman wrote:
> 
> > On Mon, Feb 01, 2021 at 11:34:30PM +0100, Ulrich Windl wrote: 
> > > On 1/27/21 7:44 AM, Shawn Creighton wrote: 
> > > > What is the quickest and most secure way to update the entire system 
> > > > including Dom0 on the first boot of a new install? I've noticed that 
> > it 
> > > > takes awhile for the updates to populate to the qubes updater when 
> > first 
> > > > connected to the net even though there are obviously updates 
> > available. 
> > > > Is there a way to expedite the process? 
> > > 
> > > I think you can always run the dom0 updater to get the updates, and for 
> > the 
> > > VMs it seems that starting one reduces the time until updates for the 
> > > corresponding template are found. 
> > > Still I'd like an explicit "check for updates"... 
> > > 
> >
> > It's also worth checking to see what templates were installed with the 
> > new install. 
> > Depending on what installer you used you may find you have outdated 
> > templates - rather than upgrading these in place it''s almost always 
> > better to install a clean new template: 
> > e.g. sudo qubes-dom0-update template-qubes-debian-10 
> >
> > As Ulrich says, starting a qube will (by default) check for updates and 
> > report back to the system - you may or may not want this to happen 
> > automatically - it's a service that can be disabled across the system. 
> >
> > You need not wait for this to happen if you use the gui updater tool - 
> > just open the tool, select "Enable updates for qubes without known 
> > available updates", and go ahead. 
> > N.B Install any new templates *before* you do this. 
> >
> > unman 
> >
> 
> So  "sudo qubes-dom0-update template-qubes-debian-10" installs a new fully 
> updated Debian 10 template? Why is it better than updating the default 
> templates?
> 
> Is it best to do all updating via Dom0? 
> 
> Thanks
> 

No, this will install a new template *as it was when it was built* - you
will still need to update that template to bring it fully up to date.
N.B. You will only need to install in this way if the install medium you have
used does not provide the latest templates - Fedora32, Debian10.

Yes, the Qubes updater tool is used to provision certain other aspects of
the template in addition to performing the update, so it is best to use
it if possible.
On Thu, Feb 04, 2021 at 06:52:22PM -0800, Shawn Creighton wrote:

-- 
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/20210205144716.GA30766%40thirdeyesecurity.org.


Re: [qubes-users] How to forward UPnP/1900 multicast to AppVM?

2021-02-02 Thread unman
On Sun, Jan 31, 2021 at 02:25:19PM -0800, Josefa Hays wrote:
> I have a service on LAN multicasting UPnP, port 1900. Other devices on
> LAN discover the service without problems. My AppVM does not detect it. 
> 
> Packets from the server looks like "protocol: UDP, port: 1900, source
> ip: $SERVER_LAN-IP, destination ip: 239.255.255.250"
> 
> How do I make the UPnP multicast reach an AppVM, i.e. how do I forward
> the traffic on port 1900 to the relevant VM? 
> 
> I have played around with
> https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world
> but without success. I am not completely new to IPTABLES, but somehow I
> lost a point somewhere. When should I use 239.255.255.250 as destination
> in iptables commands and should I use the IP of sys-firewall/app-vm.
> 
> (this is quite a replica of
> https://groups.google.com/g/qubes-users/c/BrbVe6s0aqE/m/ZsGKsMruCAAJ
> that didn't receive a follow-up answer)
> 
> 
> Best regards,
> Jo
> 

It would be helpful if you were to post the commands that you used
(*showing where you ran them*), and what "without success" means.
I'm working blind here.

I'm assuming that the netvm has an address on the 239.255.255.250
network. You don't use this as the destination address for anything.

On the netvm : a rule to forward packets from $SERVER_LAN-IP, udp:1900
to sys-firewall.
On sys-firewall: a rule to forward packets from $SERVER_LAN-IP,
udp:1900 to the target qube.
On the qube: a rule to ACCEPT INCOMING packets from $SERVER_LAN-IP, udp:1900
 
What template are you using for the sys-net, sys-firewall?

If you provide the IP addresses for sys-net, sys-firewall and qube, I
can walk you through the detail.


-- 
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/20210202163646.GC12097%40thirdeyesecurity.org.


Re: [EXT] [qubes-users] Updating a new installation

2021-02-02 Thread unman
On Mon, Feb 01, 2021 at 11:34:30PM +0100, Ulrich Windl wrote:
> On 1/27/21 7:44 AM, Shawn Creighton wrote:
> > What is the quickest and most secure way to update the entire system
> > including Dom0 on the first boot of a new install? I've noticed that it
> > takes awhile for the updates to populate to the qubes updater when first
> > connected to the net even though there are obviously updates available.
> > Is there a way to expedite the process?
> 
> I think you can always run the dom0 updater to get the updates, and for the
> VMs it seems that starting one reduces the time until updates for the
> corresponding template are found.
> Still I'd like an explicit "check for updates"...
> 

It's also worth checking to see what templates were installed with the
new install.
Depending on what installer you used you may find you have outdated
templates - rather than upgrading these in place it''s almost always
better to install a clean new template:
e.g. sudo qubes-dom0-update template-qubes-debian-10

As Ulrich says, starting a qube will (by default) check for updates and
report back to the system - you may or may not want this to happen
automatically - it's a service that can be disabled across the system.

You need not wait for this to happen if you use the gui updater tool -
just open the tool, select "Enable updates for qubes without known
available updates", and go ahead.
N.B Install any new templates *before* you do this.

unman

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


Re: [qubes-users] cryptsetup concerns

2021-01-31 Thread unman
On Sun, Jan 31, 2021 at 09:07:07AM -0600, Mason wrote:
> Hi,
> 
> Anyone know why cryptsetup isn't updated to 2.3? I asked Andrew, and it
> appears that Qubes 4.1 is using 1.7..5 cryptsetup.. 2.2 cryptsetup has a
> vulnerability in it.
> https://nvd.nist.gov/vuln/detail/CVE-2020-14382#match-5995976 .
> 
> https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
> Though, since 1.7 the default hash is SHA256 ("LUKS1 used SHA1 (since
> version 1.7.0 it uses SHA256)".
> 
> Andrew suggested I post this in the mailing list.
> 
> Thanks,
> Mason
> 

I think you are wrong here - 4.1 will use Fedora 32 in dom0, and that
*will* have cryptsetup-2.3.4-1.fc32.(Available as security update in
32 since Sept 2020)
Qubes 4.0 which uses Fedora 25 in dom0 does have the older version.

In any case, this will only bite, I think, if you allow an attacker
to attach a crafted image to dom0 - in that case you are hosed in any
case imo. 

-- 
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/20210131153452.GB572%40thirdeyesecurity.org.


Re: [qubes-users] Adding OpenGL Support

2021-01-23 Thread unman
On Sat, Jan 23, 2021 at 06:47:48PM -0800, Aaron wrote:
> Sorry for not being clear enough. I meant hardware acceleration support for
> OpenGL based applications. Possibly for Vulkan support in the future as
> well.
> 
> On Sat, Jan 23, 2021 at 6:45 PM unman  wrote:
> 
> > On Sat, Jan 23, 2021 at 06:19:43PM -0800, Aaron wrote:
> > > Hi,
> > >
> > > I have been waiting to switch using Qubes OS whenever it starts providing
> > > OpenGL support. I want to use Qt and other OpenGL based applications.
> > >
> > > What are your thoughts for future improvements to get there? How feasible
> > > is it? Could you please share your thoughts.
> > >
> > > Thank you!
> > > Aaron
> > >
> >
> > Qubes already supports openGL in AppVMS, and Qt and other applications
> > will work - what Qubes doesn't support is GPU virtualisation, so you will
> > be restricted to software based openGL, but for many Qt applications
> > that's good enough.
> >
> 

It's mentioned in the FAQ, and is not likely to be supported.
Some people have been successful in using GPU passthrough, and you'll
find numerous threads on this list on the subject. So you may be able to
get that running to support your work.

-- 
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/20210124031010.GC22786%40thirdeyesecurity.org.


Re: [qubes-users] Adding OpenGL Support

2021-01-23 Thread unman
On Sat, Jan 23, 2021 at 06:19:43PM -0800, Aaron wrote:
> Hi,
> 
> I have been waiting to switch using Qubes OS whenever it starts providing
> OpenGL support. I want to use Qt and other OpenGL based applications.
> 
> What are your thoughts for future improvements to get there? How feasible
> is it? Could you please share your thoughts.
> 
> Thank you!
> Aaron
> 

Qubes already supports openGL in AppVMS, and Qt and other applications
will work - what Qubes doesn't support is GPU virtualisation, so you will
be restricted to software based openGL, but for many Qt applications
that's good enough. 

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


Re: [qubes-users] Problems setting /etc/hosts

2021-01-20 Thread unman
On Wed, Jan 20, 2021 at 10:34:14PM +, 'awokd' via qubes-users wrote:
> mgla...@gmail.com:
> > Hi,
> > 
> > Hopefully I'm doing something silly here.
> > 
> > I want to add a couple of entries into my /etc/hosts file in a specific VM.
> > The instructions here are nice and
> > clear: https://www.qubes-os.org/doc/config-files/ except... that doesn't
> > work.
> > 
> > I've added the following to my /rw/config/rc.local :
> > echo '127.0.0.1 example.com' >> /etc/hosts
> > And after a VM restart my /etc/hosts is unchanged.
> 
> Might have to add "sudo" in front of that echo. Also, double-check that
> rc.local is set as executable and in proper script format. Does it work if
> you run it yourself from the command line?
> 
> > Also, as an aside, is it odd that rc.local is owned by root, if it's
> > something that's expected to be changed per-VM?
> 
> No, because it's only the root account that belongs to the VM.
> 

I do this with a (fairly) extensive list , and block dns.
I keep the entries in a file in /rw/config/hosts, and then in rc.local:
cat  /rw/config/hosts >> etc/hosts

Doesn't need sudo for that - and the file should be in proper format and
executable already, (but always worth checking).
Works for me.

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


Re: [qubes-users] system-config-printer gives different results in template and VM

2021-01-20 Thread unman
On Wed, Jan 20, 2021 at 11:03:43AM -0300, Franz wrote:
> On Tue, Jan 19, 2021 at 11:20 PM unman  wrote:
> 
> > On Tue, Jan 19, 2021 at 11:25:47AM -0300, Franz wrote:
> > > Hello,
> > >
> > > if I write system-config-printer in the debian template I get the
> > expected
> > > GUI to config the printer and everything works as expected.
> > >
> > > If I write the same in the VM depending from the template, I get:
> > > Printing service not available. Start the service on this computer or
> > > connect to another server.
> > > If I click on start the service, nothing happens.
> > >
> > > After many years using Qubes, the template and the VM depending from the
> > > template always behaved in the same way. I cannot understand why the
> > > template works and the VM does not.
> > >
> > > To be sure, I tried on two different VMs depending from the same template
> > > an none works
> > > Best
> > > Franz
> > >
> >
> > You don't have cups/cupsd enabled in the qube: enable it on Services tab
> > of GUI or using `qvm-service`
> >
> >
> Many thanks Unman, but why does the template not give the same error?
> 
> I understand this kind of problem should be fixed in the template, not in
> the VM that depends on the template.
> 
> But if the template works, how may I fix something that already works?
> best
> Franz

By default Debian will enable services (and start them) after
installation. This is a problem for templates, which is why there is
specific advice about installing services in to Debian templates.
By contrast Fedora does not automatically start services.

There are many services which can be enabled or disabled in an template
based qube. cups is just one of them.
That said, I'm puzzled as to why cups *is* running in your template - it
doesn't seem to be in my Debian 10.

-- 
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/20210120144346.GA930%40thirdeyesecurity.org.


  1   2   3   4   5   6   7   8   9   10   >