Re: [qubes-users] Inconsistency between `qvm-template list` and `qvm-template-gui`
Without seeing the screenshot, I think I know the issue. They are from the same repository. qvm-template lists *all* the template in the repo, whereas qvm-template-gui filters to only show the most recent supported versions. -- I never presume to speak for the Qubes team. When I comment 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/Zfq6MxZ7JMd5HZqM%40thirdeyesecurity.org.
Re: [qubes-users] Ethernet socket device not available in Network Connections
[quote] my sys-net is also sys-usb because I used the USB ethernet adapter so I think this is the problem but I don't know how to fix. [/quote] I doubt that this is the problem. Have you assigned the device to sys-net in the "devices" tab of sys-net settings. When sys-net boots up, can you run `sudo journalctl -b ` in sys-net and look for any entries relating to networking devices. It may be that you need specific drivers for the NIC, so knowing what it is would be a help. -- I never presume to speak for the Qubes team. When I comment 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/ZeO5oqfRsyO49pVY%40thirdeyesecurity.org.
Re: [qubes-users] time sync dysfunctional
On Tue, Feb 06, 2024 at 01:08:09PM +0100, 'haaber' via qubes-users wrote: > addendum: if I run "date" in a client VM it will give the right > timezone, but still has 3min of delay.. > > On 2/6/24 11:45, 'haaber' via qubes-users wrote: > > Hi, > > > > I am still on Q4.1 (no time to do a full install now). Since a few days, > > my time ran large out of sync, despite the swdate displaying normal > > functioning. I rebooted, I restarted swdate. Its log says: > > > > [INFO] date output: 10:44:44 > > > > (which is London time, but otherwise correct), my set-to-Berlin-time > > clock displays 10:42 which is 1h and 3min wrong. If it was 1h exactly, > > I'd guess a user-malconfig, but 3min ?? > > > > do you have some hints on that? > > > > Thank you, Bernhard > > Hi Bernhard My first thought was that this is a Whonix issue, but the fact that `date` has the same 3 min offset speaks against that. Let me get to a 4.1 box and I will see if I can help. Do you have locales set differently in qube from in dom0? What timezone is set in dom0? What in the qube? What in your Whonix gateway? -- I never presume to speak for the Qubes team. When I comment 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/ZcJOtWudrPFmk8qe%40thirdeyesecurity.org.
Re: [qubes-users] split-ssh question
On Fri, Sep 08, 2023 at 08:10:44AM +0200, haaber wrote: > I tried to configure split-ssh according to the tutorial on qubes pages, > in its simple version (just agent, but no keepass integration). But now > ssh offers *all* my private keys to *all* servers, which is odd, but > more annoying, it usually breaks connections after 3 "false" public keys > ... > > Clearly, I did something wrong, but I do not understand well-enough what > I should change. Did some have/solve this problem already or have a > hint for me, please? Thank you! > I dont think you did anything wrong. I think what you are looking for is something like my split-ssh-agent - This allows you to have multiple keys, allocated as you will between different agents on the ssh back-end. >From each calling qube, you specify (in policy) what agent should be called, and this is passed through to the ssh back-end to serve up the appropriate keys. You can find it at https://github.com/unman/qubes-ssh-agent or a packaged version for easy installation at https://qubes.3isec.org/tasks.html If you dont use it, it should give you one idea of how you might go on. -- 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/ZP3nIme3BRQK%2BktD%40thirdeyesecurity.org.
Re: [qubes-users] saltstack: detect the os within a running target/state.sls
On Thu, Aug 24, 2023 at 11:26:30AM +0200, lik...@gmx.de wrote:
> Hi!
>
> Running grains['os'] in a target returns always "Fedora" and grains['id']
> returns "dom0". For this reason I cannot branch in my state files for
> different os templates.
> Executing this test in such a targeted state.sls:
>
> test-grains-for-choosing-the-right-template:
> test.configurable_test_state:
> - name: "grains test"
> - changes: True
> - result: True
> - comment: {{ grains['os'] ~ ", " ~ grains['id'] ~ ", " ~
> grains['osfullname'] ~ ", " ~ grains['os_family'] }}
>
> returns
> grains['os']=Fedora, grains['os']=dom0, grains['osfullname']=Qubes,
> grains['osfamily']=RedHat
>
> Any ideas why this happens? How to branch correctly in a state file depending
> on the os of the template?
>
> Best, P!
>
When you use qubesctl it acts in the following order - dom0, templates,
template based qube. Unless you specifically exclude dom0, the state
will be applied to dom0.
You havent said what command you entered, which would have been useful,
but my guess is that you used `qubesctl state.apply ...`
If you want to target a template, then you should use:
`qubesctl --skip-dom0 --targets=LIST_OF_TARGETS .`
If you want a state file to be used BOTH for dom0 and templates, you can
use a "defensive" approach - there are examples of this at
http://github.com/unman/shaker
Use a jinja block like - {% if grains['nodename'] != 'dom0' %}
This will ensure that non-dom0 stuff gets correctly applied, while
making sure that those parts of the state dont get applied to 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/ZOh%2Bxvf2ReSaLmeP%40thirdeyesecurity.org.
Re: [qubes-users] QubesIncoming folder in /tmp ??
On Fri, Jun 30, 2023 at 12:27:41PM +0200, haaber wrote: > Hi I was wondering if it would not me preferable (at least in some VM's) > to delocalise the QubesIncoming folder in /tmp to have it "cleaned up" > regularly. It's a pain to do so manually. Is there a problem doing so ? > What would be the cleanest way to do it? A symlink ?? thank you, Bernhard > I use this in rc.local: ``` mkdir /home/user/QubesIncoming chown user:user /home/user/QubesIncoming mkdir /tmp/QubesIncoming chown user:user /tmp/QubesIncoming mount --bind /tmp/QubesIncoming /home/user/QubesIncoming ``` I dont think the chown calls are needed, but I put them in , and have not removed them. Works as you would expect. -- 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/ZJ9%2B%2BrugSSu6AW6W%40thirdeyesecurity.org.
Re: [qubes-users] How to make sys-firewall broadcast a local qube as the system-wide DNS server?
On Tue, Jun 06, 2023 at 01:24:18PM -0500, Leo28C wrote: > I managed to set up a pi-hole qube and make it my network's DNS > filtering/caching server. Ironically, it works flawlessly across my network > EXCEPT it completely breaks DNS for all other qubes in the same system. On > Debian-based qubes I figured out I can simply edit /etc/resolv.conf, while > making sure sys-firewall lets the two qubes talk to each other, as a > workaround. However this is a hacky per-qube solution and doesn't persist > across qube restarts. It would be nice to simply have sys-firewall relay > the information to all of its client qubes automatically. Any idea how to > do this? > > Thanks in advance! > You dont need to change the settings per qube at all. You haven't said *where* the pi-hole qube is located in your qubes network, or what the nature of the breakage is. I assume from what you say it is attached to sys-firewall. You can do this by editing the PR-QBS chain in nat table in sys-firewall. By default, this forwards all DNS traffic to 10.139.1.1 and 10.139.1.2 using dnat. Flush that chain and replace it with dnat rules to the IP address of your Pi-hole qube. You could do this in /rw/config/qubes-firewall-user-script or by script in /rw/config/qubes-firewall.d -- 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/ZIHekYeyI0BY5uUa%40thirdeyesecurity.org.
Re: [qubes-users] Colourful prompt
On Thu, May 04, 2023 at 05:01:38AM -0700, Andrew David Wong wrote: > On 5/3/23 4:02 AM, Qubes wrote: > > I have noticed on Fedora, the cli prompt itself is not colourful although > > the rest of the output is. Is there a way to get the prompt itself in > > colour as well? The prompt on Debian is in colour, it makes it easier to > > find things when the prompt is in colour aswell. > > > > Since this is not a Qubes-specific question, you might have better luck > searching the web for how to do this in Fedora (or Linux in general) or > asking in a Fedora (or general Linux) venue. > I wonder if this *is* Qubes specific, as it is stated that the Debian prompt is in color. (Implicit, I think, is the suggestion that the color matches the window decorations.) OP - is that what you see? That the prompt is consistent with the window decoration set by 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/ZFOgEprkEoVo25%2Bv%40thirdeyesecurity.org.
Re: [qubes-users] Injecting configuration files into appVM when it's created/started for the first time
On Wed, May 03, 2023 at 04:19:00PM +, Qubes wrote: > > 'unman' via qubes-users wrote: > > On Wed, May 03, 2023 at 12:53:00PM +, Qubes wrote: > > > > > Is there a sane way to update existing `*.conf` files on VMs that are > > > already running? > > > Is there a not-so-labour-intensive way to solve this problem? > > > > Use salt - it's easy to apply to existing qubes, as well as template. > > You can (if you wish) store the config file whole, or just the changes > > that you want to make, as part of the install. > > It also has the advantage of being self documenting. > > > I have looked over salt, albeit briefly, but it definitely does not look > like something that someone with no knowledge of salt can just jump in and > use. You have mentioned this a lot so perhaps the best person here to ask > is you. Can you maybe recommend a salt for 'dummies' guide? > I have some notes at https://github.com/unman/notes which take you through simple steps with many examples of using salt in 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/ZFMc9rIv4VwnBPg7%40thirdeyesecurity.org.
Re: [qubes-users] Injecting configuration files into appVM when it's created/started for the first time
On Wed, May 03, 2023 at 12:53:00PM +, Qubes wrote: > Is there a sane way to update existing `*.conf` files on VMs that are > already running? > Is there a not-so-labour-intensive way to solve this problem? Use salt - it's easy to apply to existing qubes, as well as template. You can (if you wish) store the config file whole, or just the changes that you want to make, as part of the install. It also has the advantage of being self documenting. -- 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/ZFKNmZMMJjV2eD40%40thirdeyesecurity.org.
Re: [qubes-users] Updating via a wireguard connection
On Fri, Apr 28, 2023 at 11:58:55AM -0700, Jeremy Hansen wrote: > I would like to configure Qubes to do its updates via a connection to a > wireguard service I have set up. > > I understand how to set up a wireguard enabled template and a qubes based on > that template following this: > > https://github.com/hkbakke/qubes-wireguard > > which works great, but I would like to force package updates to also use a > wireguard connection. I???m not quite sure what to alter to do this. Any help > would be much appreciated. > > -jeremy > The default is for updates to run in sys-net. You need to change this by changing the policy - look in `/etc/qubes/policy.d/90-default.policy` for the `qubes.UpdatesProxy` lines, and then create a new policy in `/etc/qubes/policy.d/30-user.policy` like this: `qubes.UpdatesProxy * @type:TemplateVM @default allow target=QUBE` where QUBE is the name of the qube you want to use. If you use Whonix you will need to copy the relevant Whonix lines also. Set the netvm for QUBE to be your wireguard 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/ZEzwfyp8Whgzsfcl%40thirdeyesecurity.org.
Re: [qubes-users] Template for X?
On Sat, Apr 29, 2023 at 04:53:10PM +0800, Sandy Harris wrote: [quote] Is there a template to make a qube that just runs as an X terminal? [/quote] Have you tried a minimal 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/ZEzuT6GWcmBSk%2BCi%40thirdeyesecurity.org.
Re: [qubes-users] Data recovery -- thin provisioned LVM metadata (?) problem
On Tue, Apr 25, 2023 at 08:19:48AM +0200, haaber wrote: > Dear all, > > I had a lethally bad hardware failure on computer. Since I had to buy a > new machine this took a while, now I try to save some data: the old SSD > is attached to a brand-new qubes via usb adapter. I started > > sudo pvscan and sudo vgscan --mknodes and sudo vgchange -ay as > manual says. > > unexpected output: > > PV /dev/mapper/OLDSSD VG qubes_dom0 lvm2 [238.27 GiB / <15.79 > GiB free] > Total: 1 [238.27 GiB] / in use: 1 [238.27 GiB] / in no VG: 0 [0 ] > Found volume group "qubes_dom0" using metadata type lvm2 > Check of pool qubes_dom0/pool00 failed (status:1). Manual repair > required! > > 1 logical volume(s) in volume group "qubes_dom0" now active > > then I consulted dr. google for help, and found little help. This one > > https://mellowhost.com/billing/index.php?rp=/knowledgebase/65/How-to-Repair-a-lvm-thin-pool.html > > suggested to deactivate volumed so that a repair can work. Only swap was > active, I deactivated it. But repair does not work: > > lvconvert --repair qubes_dom0/pool00 > terminate called after throwing an instance of 'std::runtime_error' > what(): transaction_manager::new_block() couldn't allocate new block > Child 21255 exited abnormally > Repair of thin metadata volume of thin pool qubes_dom0/pool00 failed > (status:-1). Manual repair required! > > > So now I am struck and ask for help! This is not purely qubes-related, I > known, but I hope to find competent help within the community. > > > cheers, Bernhard > Hi Bernhard Havent seen you for a while. Nice to see you back. I've been able to fix this in the past by deleting snapshots - I'm not sure if this will work for you. If I were you I would take a copy of the SSD with dd, and then start to prune - what happens if you use lvremove against some of the larger snapshots? 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/ZEfjwfZ7zXBywyef%40thirdeyesecurity.org.
Re: [qubes-users] Modifying /etc/hosts in dispVM
On Thu, Apr 20, 2023 at 11:29:08AM +, Rusty Bird wrote: [quote] 'host' isn't suitable for testing this, because it never looks at the [/quote] Right - neither are most of the *other* DNS utilities - ping should do. Or `getent hosts ...` -- 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/ZEEswfwmKYSuiE4w%40thirdeyesecurity.org.
Re: [qubes-users] Modifying /etc/hosts in dispVM
On Wed, Apr 19, 2023 at 07:06:19AM -0700, john.e...@gmail.com wrote: > I haven't been able to figure out how I can modify /etc/hosts in a dispVM > so that my entry (such as 10.1.1.1 myhost.example.commyhost) will be > used instead of DNS. > > I'm trying to direct my traffic to a different host than the one listed in > DNS. > > Anyone know an easy fix to this? Thanks. > It's a disposable - you need to set the change in the disposable template. Add this to /rw/config/rc.local in the disposable template: echo "10.1.1.1 myhost.example.com" >> /etc/hosts That will take effect in the disposable template, and in every disposable that uses it. I use this often because I block DNS for many qubes, provide hosts entries, and whitelist those IPs. -- 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/ZEAGmG0Ql3wFocZf%40thirdeyesecurity.org.
Re: [qubes-users] dependency problem after upgrading standalone debian 11 VM
On Fri, Apr 14, 2023 at 04:10:29PM +0200, qubes-li...@riseup.net wrote: > Hi uman, > > thanks for your reply. > > 'unman' via qubes-users: > > Exactly this issue arose on GitHub - it is, as you say, because you did > > not update the qubes repository definition in timely way. > > You can read the issue > > [here](https://github.com/qubesos/qubes-issues/issues/7865) > > > The resolution is to follow the steps in the upgrade script - courtesy > > of Marek: > > ``` > > The source of the problem is that in R4.1 we actually stopped shipping own > > duplicated xen packages, and are relying on those from official Debian > > repositories. But the upgrade path requires manual step because of that. > > The in-place R4.0 -> R4.1 upgrade tool handle that automatically, but in > > case of manual upgrade, see this part: > > https://github.com/QubesOS/qubes-dist-upgrade/blob/release4.0/scripts/upgrade-template-standalone.sh#L37-L72 > > ``` > > Yes I know about this github ticket, I mentioned in my last email, but > I have the impression that these step can not be used _after_ > running 'apt update; apt upgrade; apt dist-upgrade' anymore - which is the > situation I'm in. > > Is there also a way to recover a system after the 'apt upgrade' step happened > already? > I'd probably be rolling back most of your recent changes, and starting again, after making sure that I have a decent backup of the qube in its current state. You need to roll back those packages, and -f should work for the install. I have some old templates hanging about - if you can wait until tomorrow I'll pull one and work through the process 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/ZDltBO75pErMxI/A%40thirdeyesecurity.org.
Re: [qubes-users] dependency problem after upgrading standalone debian 11 VM
Exactly this issue arose on GitHub - it is, as you say, because you did not update the qubes repository definition in timely way. You can read the issue [here](https://github.com/qubesos/qubes-issues/issues/7865) The resolution is to follow the steps in the upgrade script - courtesy of Marek: ``` The source of the problem is that in R4.1 we actually stopped shipping own duplicated xen packages, and are relying on those from official Debian repositories. But the upgrade path requires manual step because of that. The in-place R4.0 -> R4.1 upgrade tool handle that automatically, but in case of manual upgrade, see this part: https://github.com/QubesOS/qubes-dist-upgrade/blob/release4.0/scripts/upgrade-template-standalone.sh#L37-L72 ``` -- 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/ZDlNncRfNAH//fIE%40thirdeyesecurity.org.
Re: [qubes-users] Kali Linux Purple - Defense
On Tue, Apr 04, 2023 at 10:11:19PM -0700, Foilsurf wrote: > Hello, > which of the out of the Box Defense features of the new *Kali Linux Purple*, > would be very nice to have also in *QubesOS *to raise the defense bar? (the > attacks also get every day harder...) > Kind Regards > I see that they emphasize defensive tools - mainly scanners, and IDS - but is there yet detail on configuration features? I havent yet seen that. Also, there's no sign that they will be moving from Debian testing. -- 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/ZC2DkxvwJhiYiPvE%40thirdeyesecurity.org.
Re: [qubes-users] How Qubes handles the start of services
On Mon, Mar 27, 2023 at 06:33:26PM +0200, r.wiesb...@web.de wrote: > Hi uman, > > that was the reference in qubes-doc that I found before and that I could > not find today when I was writing this email. However, it does not > explain what the advantage of this two-switch-model is compared to just > run the services defined in the per-qube services tab/setting without > the dependence on being enabled in the template. > That approach would render adding support for [any generic] systemd > service not only "pretty simple" but would make every systemd service > compatible "by design". I think that a generic systemd service is already compatible by design:if you install such a service and enable it in the template it will be enabled in the qubes using that template. Is that not so? The current system provides a simple condition that gives granular control over services on a per qube basis. The same control can be achieved by *disabling* the service in the template, and having a switch that enables the service and starts it in the qube. I do this myself in some cases. (From dom0 with qvm-run, or with entries in rc.local, e.g.) Both approaches require some action in the template as well as action in the qube. So both are "two-switch". The current mechanism provides a dead mans handle but allows services to start at an early stage. You are not obliged to use it for other services. -- 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/ZCL4GLiMKwI%2B2btY%40thirdeyesecurity.org.
Re: [qubes-users] How Qubes handles the start of services
On Mon, Mar 27, 2023 at 03:48:15PM +0200, r.wiesb...@web.de wrote: > Hi there, > > every VM/qube has a "services" tab in its settings window. It seems like > Qubes is designed in a manner that requires two switches for a service: > it needs to be enabled in the template *and* requires an entry in > "services" tab. > > My expectation was that when selected in the "services" tab, qubesrc (or > any other instance) will just start the corresponding service in the VM. > During troubleshooting I found out that it is designed as above, but I > could not find the reason for this design decision. > > At least the "services tab" should have a red text warning that it is > required to enable the service in the template as well in order to not > confuse users the way it confused myself. > > > best, > Ron > This is a long standing design. The process is explained at https://www.qubes-os.org/doc/qubes-service/ The text on the service tab is unclear - it *does* say that the service will be turned on. I've raised an issue to have this clarified. -- 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/ZCGwR5nTbOD/kLIl%40thirdeyesecurity.org.
Re: [qubes-users] Odd behavior wile running two separate Whonix gateways
On Fri, Mar 24, 2023 at 04:23:48AM +, tiesta_symonne61 via qubes-users wrote: > I have two Whonix gateways, the default sys-whonix and a sys-whonix-clone. > Both are attached to different net vm's. > > The problem is that all qubes that have sys-whonix-clone as its net vm > show up under sys-whonix's tray icon, not sys-whonix-clone's. I'm pretty > sure the actual traffic is being routed through the correct gateways, but > my only metric for knowing that is looking at CPU usage while stressing > the connection and making sure the correct chain of net vm's light up. > [quote] Is this just a GUI quirk, or should I worry about actual risk of traffic getting mixed between the two gateway qubes? [/quote] It sounds like a GUI bug - you could check what is happening by running a sniffer on sys-whonix, or by examining counters on the firewall rules. I don't have whonix installed to e able to tell you if the tools for this are installed. (You could try running `iptables -L -nv -t nat` and seeing if the counts for one of the errant qubes increments. Report back.) -- 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/ZB2cU6he45EzVAtq%40thirdeyesecurity.org.
Re: [qubes-users] 'qvm-copy' and 'qvm-copy-to-vm' in AppVM
qvm-copy-to-vm is deprecated and will be removed. -- 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/ZB2bCFm2zx1DMg2v%40thirdeyesecurity.org.
Re: [qubes-users] Shutdown Delay
On Wed, Dec 28, 2022 at 11:00:18AM +0100, Ulrich Windl wrote: > Hi! > > Am I the only one that sees extra shutdown delays? > It seems that everything is unmounted, but still thing hang; unsure what that > is. See attachment. > What surprises me is that crypto seems to be stopped before unmount. > > Regards, > Ulrich > No, I often see excessive shutdown delays. -- 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/Y7RFxd4RbhGW9VSQ%40thirdeyesecurity.org.
Re: [qubes-users] No editor at all in 'fedora-36-minimal' template?
On Sun, Oct 09, 2022 at 05:34:50AM -0700, Viktor Ransmayr wrote: > Is it correct, that this template does not provide any editor 'package' at > all? No, there's nano -- 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/Y0LH3cSkr4bcm7CS%40thirdeyesecurity.org.
Re: [qubes-users] firefox-esr and brave-browser work, but firefox, nautilus, thunar, gnome-terminal, xterm do not
On Wed, Aug 24, 2022 at 07:12:45PM -0700, Andrew David Wong wrote: > On 8/24/22 2:31 PM, Franz wrote: > > Hello, > > the following command is intended to run an application in a new DVM: > > > > qvm-run --dispvm=debian-11-dvm --service qubes.StartApp+ > > > > If in place of I put firefox-esr or brave-browser it works, the > > new DVM is opened and the application works as expected. > > > > But if in place of I put firefox, nautilus, thunar, > > gnome-terminal, xterm the DVM starts, but immediately after closes with > > error: > > command failed with code:1 > > > > Any idea to solve it or is it just a bug? > > > > > > > > firefox-esr and brave-browser work, but firefox, nautilus, thunar, > > gnome-terminal, xterm do not > > > > You might be missing .desktop files or something for the ones that aren't > working. That seems to be a common problem. > > I prefer the simplicity and reliability of this type of command: > > qvm-run --dispvm=debian-11-dvm > > E.g.: > > qvm-run --dispvm=debian-11-dvm nautilus > In Debian, the desktop file is firefox-esr.desktop. The application is available using either firefox or firefox-esr. When you use the --service form of qvm-run it references the desktop files, as Andrew said.(The Debian package is also called firefox-esr, and `firefox` is a shell script that calls `firefox-esr`) In Debian, the desktop file for xterm is `debian-xterm.desktop`, so that's how you must address it if you use the --service form. Nautilus is org.gnome.Nautilus.Desktop etc. Some of the examples you gave have a different root cause, because of the way that those applications work. For example, gnome-terminal will call the gnome-terminal server and spawn an instance of the terminal. Because of the way that disposables work, when that first call completes, the disposable shuts down, so you never see a terminal window. Qubes provides qubes-run-gnome-terminal to help with 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/YweGRH4YV%2BrCBG7J%40thirdeyesecurity.org.
Re: [qubes-users] Qubes Contrib repository
On Sat, Aug 13, 2022 at 10:02:15PM +0200, Qubes wrote: > Qubes wrote: > > I guess one way to see what is available in the contrib repo is to look > > on [Github][1], but is there a way to list the available packages in the > > contrib repo from cli? > > > > Assuming that one has already added the contrib repo, > > > > ``` > > sudo qubes-dom0-update qubes-repo-contrib > > ``` > > > > [1]: (https://github.com/QubesOS/qubes-issues/issues/7389) > > > Oops, wrong URL provided, > > > [1]: https://github.com/QubesOS-contrib > qubes-dom0-update --repo=qubes-contrib-dom0-r4.1-current --action=list -- 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/YwJBU2L0YStzrudJ%40thirdeyesecurity.org.
Re: [qubes-users] Re: Problems with Timesynchronization
> > Can you please comment on how it is possible, that > "ConditionPathExists=/var/run/qubes-service/clocksync was not met" - and - > ideally, how to resolve that issue. > That suggests that you do not have the clocksync service enabled. Set it with `qvm-service --enable QUBE clocksync` or `qvm-features QUBE service.clocksync 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/YuZmeyeQ/YQ9JZb4%40thirdeyesecurity.org.
Re: [qubes-users] qvm-firewall command error
On Wed, Jul 27, 2022 at 03:59:03PM -0700, Howard Chen wrote: > Currently, I am configuring my NetworkIT qube firewall with the > qvm-firewall command in dom0 terminal. However, when I entered this, it > showed this following error: > > [Howard@dom0 ~]$ qvm-firewall NetworkIT add dsthost 10.137.0.5 You havent given a valid rule: parameters are wrong and no action given. Look at the manpage and qvm-firewall --help. qvm-firewall NetworkIT add accept 10.137.0.5 OR qvm-firewall NetworkIT add accept match dsthost=10.137.0.5/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/YuPSDNU3idfZ7s8C%40thirdeyesecurity.org.
Re: [qubes-users] qubes core agent networking iso building help
On Tue, Jul 19, 2022 at 09:28:00AM -0700, Howard Chen wrote: > Thanks, Unman. This will take me about 18 to 19 months to finish and > publish if I have the right tools that I need and the codes probabilities > for that to happen. > On Tuesday, July 19, 2022 at 4:08:06 AM UTC-7 unman wrote: > > > On Mon, Jul 11, 2022 at 11:47:19AM -0700, Howard Chen wrote: > > > I need help to build the qubes core agent tools for the new OS that > > called > > > LinuxFX. Here is the story. > > > > > > I stumped across the YT for other Linux OS that functions similar to > > > Windows. This OS that was introduced to me by a YouTuber goes by "Linux > > For > > > Everyone" with a video called "This Linux OS Looks EXACTLY Like Windows > > > 10!" This video talks about this OS that I am working with and will > > > implemented into Qubes if I can do it. The question is: How to create an > > > ISO file in qubes? > > > > > I'm not clear what you are asking. > > Do you want to build the core agent tools? Read the docs on > > qubes-builder. LinuxFX is based on Ubuntu so you can probably use the > > Ubuntu tools as is. > > Do you want to build a template? Treat it as a flavor of Ubuntu, so you > > build (e.g) focal+linuxfx. > > > > If you want to create a Qubes based on LinuxFX instead of Fedora, then > > that's far more difficult. You'll need to build all the components for > > Ubuntu. > > An alternative would be to use Fedora as dom0, and try to implement > > LinuxFX as sys-gui. > > Whatever your aim you should read the docs on building. > > I still dont know what you are trying to do. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YtfkfM2CYHscJ942%40thirdeyesecurity.org.
Re: [qubes-users] KDE on 4.1
On Tue, Jul 19, 2022 at 01:26:13PM +0200, Qubes wrote: > Qubes wrote: > > 'unman' via qubes-users wrote: > > > On Tue, Jul 19, 2022 at 08:41:40AM +0200, Qubes wrote: > > > > The procedure to install KDE in 4.1 doesn't seem to work, is > > > > that expected > > > > behavior? > > > > > > Yes, the group isn't present. > > > qubes-dom0-update kde-settings-qubes > > > > > > > Is this the way of installing KDE now which means the documentation must > > be updated or is this just a workaround? > > > > Also, would the correct procedure to remove KDE still be as per the > documentation, > > "sudo dnf remove kdelibs plasma-workspace" dnf remove kde-settings-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/YtaVV8RIYtSiOB4R%40thirdeyesecurity.org.
Re: [qubes-users] KDE on 4.1
On Tue, Jul 19, 2022 at 11:49:04AM +0200, Qubes wrote: > 'unman' via qubes-users wrote: > > On Tue, Jul 19, 2022 at 08:41:40AM +0200, Qubes wrote: > > > The procedure to install KDE in 4.1 doesn't seem to work, is that expected > > > behavior? > > > > Yes, the group isn't present. > > qubes-dom0-update kde-settings-qubes > > > > Is this the way of installing KDE now which means the documentation must be > updated or is this just a workaround? > The documentation is in transition from 4.0 to 4.1 This will be in the update. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YtaUVZo/UiNn99fe%40thirdeyesecurity.org.
Re: [qubes-users] qubes core agent networking iso building help
On Mon, Jul 11, 2022 at 11:47:19AM -0700, Howard Chen wrote: > I need help to build the qubes core agent tools for the new OS that called > LinuxFX. Here is the story. > > I stumped across the YT for other Linux OS that functions similar to > Windows. This OS that was introduced to me by a YouTuber goes by "Linux For > Everyone" with a video called "This Linux OS Looks EXACTLY Like Windows > 10!" This video talks about this OS that I am working with and will > implemented into Qubes if I can do it. The question is: How to create an > ISO file in qubes? > I'm not clear what you are asking. Do you want to build the core agent tools? Read the docs on qubes-builder. LinuxFX is based on Ubuntu so you can probably use the Ubuntu tools as is. Do you want to build a template? Treat it as a flavor of Ubuntu, so you build (e.g) focal+linuxfx. If you want to create a Qubes based on LinuxFX instead of Fedora, then that's far more difficult. You'll need to build all the components for Ubuntu. An alternative would be to use Fedora as dom0, and try to implement LinuxFX as sys-gui. Whatever your aim you should read the docs on building. -- 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/YtaQkhcrfP9geurm%40thirdeyesecurity.org.
Re: [qubes-users] KDE on 4.1
On Tue, Jul 19, 2022 at 08:41:40AM +0200, Qubes wrote: > The procedure to install KDE in 4.1 doesn't seem to work, is that expected > behavior? Yes, the group isn't present. qubes-dom0-update kde-settings-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/YtZ9X8dYhbJrwGxe%40thirdeyesecurity.org.
Re: [qubes-users] VM initial memory
On Wed, Jul 13, 2022 at 05:28:01PM +0200, Qubes wrote: > Hi > > I am trying to figure out the significance of the "Initial memory" setting > of a VM. Does it make any difference? For example VM A and B. A is > configured with 500 MB initial memory and 2000 MB Max memory. VM B is > configured with 1000 MB Inintial memory and also 2000 MB Max memory. Is > there a situation where the initial memory will play a role? > > I did once have a problem where, I think a think at the time it was a Fedora > 32 template that did not boot when its initial memory was set at 200 MB. > Other than start up problems however, does this setting affect anything in > any way for one to make it a genuine consideration? > I think that at present a qube will start with maxmem and then balloon down to initial memory. If memory is set too low the qube wont start, as you say. I don't think that memory allocated will drop below "Initial memory", so if you are tight on RAM it makes sense to reduce 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/YtKuABN6H3K4Zbc0%40thirdeyesecurity.org.
Re: [qubes-users] Onion site and repos are down
I am advised that the onion server is back online 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/YtCqc8o85LjB6Ge9%40thirdeyesecurity.org.
[qubes-users] Onion site and repos are down
I am advised that there is a hardware fault, and the onion site is down. We're working on 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/Ys4ONaNdHTxlzK5v%40thirdeyesecurity.org.
Re: [qubes-users] Using the second os on the (dual-booted) system as a VM
On Mon, Jul 11, 2022 at 05:14:05AM -0700, MUT wrote: > I want to try creating maybe a standalone VM that would mount a partition > on my hard drive which has a seperate os installed on it as its root, and > use that as a VM. Effectively that would let you use the second OS you have > installed on a computer besides Qubes as a VM in qubes. I searched around > the web to see if someone has done it, but couldn't find anything. > > I'd be very thankful for any help or advice regarding that, will post some > updates after I actually try it. > I'm surprised you couldn't find anything on this. You want to create a block device using the other partition and use it in place of the standalone root. You can customise the standalone definition or do some jiggery pokery to get it running. I hacked about with this and will look out my notes. -- 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/YsxPMvMBBOtJ%2B3oU%40thirdeyesecurity.org.
Re: [qubes-users] Fedora 36 templates available
On Tue, Jun 28, 2022 at 03:42:22AM +, Metatron wrote: > On Mon, Jun 27, 2022 at 07:41:57PM -0700, Andrew David Wong wrote: > > Dear Qubes Community, > > > > New Fedora 36 templates are now available for Qubes 4.1! > > Is anyone else having this problem: > # sudo qubes-dom0-update qubes-template-fedora-36 > Redirecting to 'qvm-template install fedora-36' > Downloading 'qubes-template-fedora-36-0:4.0.6-202205270243'... > qubes-template-fedora-36-0:4.0.6-202205270243: 0%| | 0.00/1.72G > [00:00 qubes-template-fedora-36-0:4.0.6-202205270243: 0%| | 0.00/1.72G > [00:01 ERROR: [Errno 2] No such file or directory: > '/root/.cache/qvm-template/tmps3hgqf8e/qubes-template-fedora-36-0:4.0.6-202205270243.rpm.UNTRUSTED' > > Thanks! > It was an issue, but has probably already been resolved by time. -- 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/Yr3FegxfDms0k%2Bb5%40thirdeyesecurity.org.
Re: [qubes-users] Problems with announced Fedora 35 templates
On Sun, Jun 12, 2022 at 01:44:41AM -0700, Viktor Ransmayr wrote: > Hello Steve, > > stevenlc...@gmail.com schrieb am Samstag, 11. Juni 2022 um 17:52:19 UTC+2: > > > > > It looks to me that your current sys-firewall template is not up to date > > for your current R4.1 version, or just broken. If you have any other > > templates on your system (e.g. debian-11, fc35-minimal, fc35-xfce ) you > > might want to try switching sys-firewall to something else and then try to > > use qvm-template to download a working template of the f35 flavor. > > > > Your suggestion was obviously the next step I tried. - Unfortunately again > it did not improve anything :-( > > Here are my logs & notes: > > ### > > Change the template for 'sys-firewall' from 'fedora-34' to 'debian-11'. > > * Close all Study-VMs - and - close the affected 'sys-whonix' VM ... > * Perform the template change ... > * Try now to download the new 'fedora-35' templates - Not OK - See > "Log-001". > > ### Log-001 > > [vr@dom0 ~]$ > [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35 > Redirecting to 'qvm-template install fedora-35' > [Qrexec] /bin/sh: 0: cannot open /etc/qubes-rpc/qubes.TemplateSearch: > No such file > ERROR: qrexec call 'qubes.TemplateSearch' failed. > [vr@dom0 ~]$ > [vr@dom0 ~]$ > [vr@dom0 ~]$ sudo qubes-dom0-update --clean --console --show-output > Using sys-firewall as UpdateVM to download updates for Dom0; this may > take some time... > 0 files removed > Unable to detect release version (use '--releasever' to specify release > version) > Fedora 32 - x86_64 - Updates6.3 MB/s | 35 MB > 00:05 > Fedora 32 - x86_64 6.3 MB/s | 63 MB > 00:09 > Qubes Dom0 Repository (updates) 572 kB/s | 3.8 MB > 00:06 > Last metadata expiration check: 0:00:05 ago on Sun Jun 12 09:48:13 2022. > Dependencies resolved. > Nothing to do. > Complete! > No packages downloaded > No updates available > [vr@dom0 ~]$ > > ### > > Thanks a lot for your support in trying to find a solution for my problem. > > With kind regards, > > Viktor > Hi Viktor My vanilla debian-11 template *does* have /etc/qubes-rpc/qubes.TemplateSearch. That file is provided by qubes-core-agent-dom0-updates. I currently have version 4.1.36-1 I suggest you make sure that you have that package installed and that your debian-11 template is fully updated. That should resolve the problem. 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/YqXgxrBlONIjjy%2B9%40thirdeyesecurity.org.
Re: [qubes-users] qubes update -- how to hold an old kernel ??
On Fri, Jun 10, 2022 at 08:55:41AM +0200, haaber wrote: > Recent QSB made me run the qubes-update. Regrettably, it wants to remove > a kernel version that I need to hold (in case of foreseeable problems > with newer ones). How can I freeze that older version and forbid its > uninstall? > > best, Bernhard > Hi Bernhard There are a number of things you can do: the simplest - Increase the number of kernel packages that are retained: In /etc/dnf/dnf.conf change installonly_limit=3 to some higher number. Then manually delete kernel packages that are intermediate. That way you keep the working version *and* get the updates so you can try them as they come in. There used to be a plugin to lock dnf updates to a specific version, but I think that disappeared a few years ago. You can try `dnf mark install kernel-VERSION` which *should* hold that package version on the system, but that hasn't always worked for me. There is another simple approach - run the update while booted in to the kernel you want to hold. dnf wont remove the running kernel, and will uninstall newer versions to stay within the installonly_limit you have set. Some combination of these should allow you to hold (some) older kernel version while still allowing you to try updated kernels. 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/YqXeEJ06Mr%2BCXl51%40thirdeyesecurity.org.
Re: [qubes-users] Failing Salt code: out of ideas and wrong error
On Tue, May 24, 2022 at 11:54:27PM +0200, 'Johannes Graumann' via qubes-users
wrote:
> Can any one point me to why the following fails? I have been banging my
> head against this for a while ...
>
> --- SNIP ---
> create bind dirs config file:
> file.managed:
> - name: /rw/config/qubes-bind-dirs.d/50_user.conf
> - makedirs: True
> - mode: 644
> - dir_mode: 755
>
> {% set binddirs = ['/usr/local'] %}
>
> {% for binddir in binddirs %}
> configure '{{ binddir }}' to be persistent:
> file.replace:
> - name: /rw/config/qubes-bind-dirs.d/50_user.conf
> - pattern: "^binds+=( '{{ binddir }}' )$"
> - repl: "binds+=( '{{ binddir }}' )"
> - append_if_not_found: True
> {% endfor %}
> --- SNIP ---
>
> The corresponding error ("State 'create bind dirs config file' in SLS
> 'custom_dom0.sys-vpn-mpihlr_assert_vpn_setup' is not formed as a list")
> is a complete red herring, as the so called first part by itself works
> just fine and only fails when I add the latter (jinja) part ...
>
> How do I properly deal with the single quotes in `pattern` and `repl`?
>
> Thanks for any pointers.
>
> Sincerely, Joh
>
>
Hi Joh
Change the closing tag on the for statement to "-%}"
This is, I think, salt specific - according to the jinja specs it will remove
whitespace
Your use of single quotes in pattern and repl will be fine.
A simpler (and lazier) formulation would use file.append:
{% for binddir in binddirs %}
configure '{{ binddir }}' to be persistent:
file.append:
- name: /rw/config/qubes-bind-dirs.d/50_user.conf
- text: "binds+=( '{{ binddir }}' )"
- makedirs: True
{% endfor %}
You can drop the explicit file.managed in this case.
unman
--
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/Yo44Q9qWm3fcpctZ%40thirdeyesecurity.org.
Re: [qubes-users] Qubes 4.1: How to set private storage max size using SALT?
You have to include a call to qvm-volume in your state file. 'qvm-volume extend QUBE:private 50G': cmd.run -- 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/Yjn32556ftFbeke%2B%40thirdeyesecurity.org.
Re: [qubes-users] Re: Qubes 4.1 qrexec issue?
On Wed, Mar 09, 2022 at 11:20:53AM +, 'taran1s' via qubes-users wrote: > > > taran1s: > > I have an issue with Split GPG as well as with opening files in the > > disposable VMs and with the qrexec in the guide How to use Monero > > CLI/daemon with Qubes + Whonix too. > > > > https://www.getmonero.org/resources/user-guides/cli_wallet_daemon_isolation_qubes_whonix.html > > > > > > Split GPG > > > > Opening Thunderbird, I get following errors in the notification popup: > > > > Denied: whonix.NewStatus > > Denied whonix.NewStatus+status from work-email to sys-whonix > > > > I have to as well make every gpg action confirm in the Dom0 Operation > > Execution with Target GPG backend. > > > > Using dispVMs from within AppVM > > > > When trying to convert file or open it in the disposable VM from within > > the normal AppVM, I get an error popuplike : > > > > Denied: qubes.PdfConvert > > Denied qubes.pdfConvert from work-email to @dispvm > > > > Any advice appreciated! > > Is this mailing list still active or one needs to better go to a different > place? > Still active, but the Forum has more traffic, although it's often low grade and noisy. On your questions, the first looks like a Whonix issue - Patrick has asked that Qubes-Whonix questions be put in the Whonix forums, where they will get better oversight. The second looks like permissions - look in the policy file at /etc/qubes-rpc/policy/qubes.PdfConvert -- 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/YiittlokWGpOaiKk%40thirdeyesecurity.org.
Re: [qubes-users] Audio leakage?
This sounds familiar. I think that there was exactly the same issue raised in the Qubes Forum. afaik that was resolved to feedback, and not to intra-qubes bleeding. I'll check, (or you can), and update. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YflIXRkqNJ2w8uXa%40thirdeyesecurity.org.
Re: [qubes-users] Help using qubes as testing VMs
On Tue, Jan 18, 2022 at 12:49:34PM -0600, Eric W. Biederman wrote: > > Can someone tell me if I am missing something? > > I do a lot of testing of linux kernels. A bunch of that I have > historically done in qemu with kvm support. Unfortunately nested > hardware virtualization does not work. Which means for testing > for race conditions and the like I need to run the kernels in > their own HVM. > > I use an HVM so I can update the kernel in /boot and reboot the qube and > be running the kernel I am testing. It would be nice if I could use a > throw-away qube that just boots with a kernel of my choosing but using > an stand-alone qube is fine. > > Where I run into practical problems is when I want to place specific > files into my testing qube. I have not figured out how to ssh into > the qube from another qube, nor have I figured out how to use qvm-copy. > The best I have right now is to have an external machine that I copy > things to and then copy them back, which seems like a real hack. > > I also have not figured out how to get a serial console from such a qube > only a graphical one which makes it more difficult than I would like > to capture errors. > > I looked at installing the qubes-core-agent package in my testing HVM > but it has too many dependencies and installing it makes it impossible > to test what I would like to test. That is assuming someone has even > packaged it for the distro I need to test on. > > Am I missing something? Is there an easier more straight forward way to > setup a testing qube? Is it possible to setup a virtual serial console > to a qube? Is it possible to ssh to a qube from another qube? > > Eric Hi Eric You should probably check out the fine documentation: https://www.qubes-os.org/doc/managing-vm-kernels/ has information about using different kernels, including kernels provided by the qube. https://www.qubes-os.org/doc/firewall has information about enabling networking between qubes. If you are using HVMs you can, in some cases, install qubes packages, and then use tools like qvm-copy. I say, in some cases, because this wont work with some targets, like Ubuntu standalones. 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/YedXTcXJyVZbFbxO%40thirdeyesecurity.org.
Re: [qubes-users] Why is dom0 so long behind in versions?
On Tue, Jan 18, 2022 at 02:09:30PM +0100, 'Rune Philosof' via qubes-users wrote: > On Tue, Jan 18, 2022 at 1:24 PM 'awokd' via qubes-users < > qubes-users@googlegroups.com> wrote: > > > 'Rune Philosof' via qubes-users: > > > Why not use fedora 35 for dom0? > > > Wouldn't it make it easier to maintain, while also getting better > > hardware > > > support? > > > > > https://www.qubes-os.org/faq/#why-is-dom0-so-old > > > > Thanks. But that does not answer any of the questions. > It only says why it is not necessary to run a newer one. > Every Qubes release goes through a significant testing round - Qubes 4.1 is in the midst of that with (now) rc4, but has already been through an alpha and beta round. At that time Fedora 32 was still a recent release. Every release has to draw a line somewhere - it would not be feasible to keep updating dom0 as the testing rounds progress. -- 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/YedPUno21wKxfsvj%40thirdeyesecurity.org.
Re: [qubes-users] How is the "update qube" selected/ how do I select it manually?
On Tue, Dec 21, 2021 at 08:01:43PM +0100, r.wiesb...@web.de wrote: > it seems like the docs don't answer that, do they? > > https://www.qubes-os.org/doc/how-to-update/ > [quote] There is only a global setting for dom0 Updates, but how does it work for other qubes? [/quote] Individual templates take their updateVM from the policy file - in 4.0 this is /etc/qubes-rpc/policy/qubes.UpdatesProxy. You edit this file if you want to change the Update Proxy for a template. In 4.1 the default is in /etc/qubes/policy.d/90-default.policy - if you want to change the setting, you should create an entry in (e.g.) 30-user.policy The policy files are self documenting, but if you need help with the format feel free to ask. -- 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/YcKD9ZpygBIrdB6G%40thirdeyesecurity.org.
Re: [qubes-users] keyserver in template with saltstack unreachable
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 ...
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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)
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?
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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?
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
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
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
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?
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
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?
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
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
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?
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
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
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 ~/ ?
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.
