Re: Solved: [qubes-users] external CD writer
On Sat, 2020-05-02 at 23:25 +0200, dhorf-hfref.4a288...@hashmail.org wrote: > On Sat, May 02, 2020 at 11:01:06PM +0200, Olaf Klinke wrote: > > > I presume dom0 did not recognize the drive as a USB device and > > hence > > refuses to attach as such? `qvm-usb` yields the empty list. > > oh right, you just came full circle: > attaching USB devices is not going to work without a usbVM. > Where in the documentation is that stated? The manpage of qvm-device does not mention this. The only hint is that all examples of qvm-usb in the documentation show sys-usb as backend. > > > The only remaining question is: Did I buy a shitty drive or will > > any > > external CD writer behave this way? > > no, you just dont have your qubes setup properly. > once you have a sys-usb ... qvm-usb should work just fine. > > for how to do that: see other thread. :P > > > Okay, so let me try to get this straight, for the record. 1. USB generally is bad, it should be avoided or contained. 2. Putting the USB keyboard into one container together with other untrusted USB devices is even worse, since whoever controls your keyboard, controls your computer. 3. Putting the USB keyboard in a qube can and has locked users out of their systems. 4. If possible, keep the input devices (and only those) attached to dom0 while attaching all others to sys-usb. Luckily I seem to have two USB controllers for my peripheral USB ports, so I can easily separate input- from other USB-devices. Is (4) possible/recommended? The documentation shows how to hide _all_ USB controllers from dom0, so I assume one can also choose to hide _some_. -- You received this message because you are subscribed to the Google Groups "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/6cae63d2e9b9ca2d08c44b1ed57ba8012cf2154c.camel%40aatal-apotheke.de.
Re: Antw: [EXT] [qubes-users] To the Qubes developers (German translation) - An die Qubes Entwickler (Ăbersetzung auf Deutsch)
On Mon, 2020-05-04 at 21:38 +0200, Ulrich Windl wrote: > > > > Caroline Villinger schrieb am > > > > 03.05.2020 um > 08:11 in Nachricht > < > 13676_1588486297_5EAE6099_13676_409_1_4a35faa1-f58a-4d47-9818-a852c0f07612@goog > egroups.com>: > > Hello dear Qubes developers, > > > > I would like to ask you whether we can translate the Qubes software > > into > > German. > > Would you be willing to give us all the files we need for the > > translation? > > When we are done with the translation, we would send you the German > > version > > so that you can install it in the Qubes software. > > This means that the user can choose whether he wants to install the > > German > > language or the English language when installing new software. > > > > If you agree, it would be very nice if you could give us an answer. > > Those who are old enough might remember the "LST" (Linux Support > Team) efforts > of translating all Linux kernel messages to German. AFAIK they gave > up long > ago. Most likely because it's a _huge_ amount of work that needs > updates every > release. > Likewise for Qubes: My guess is that you need something like 5000 > hours of > work, and you can be sure: The task cannot be automated. > For example there are different English words that map to the same > German > word, and two different German works may map to the same English > word. ... and it would be fun finding out what the fixed points of those translations are. I agree that a full translation would be an awful lot of work. But for starters I'd be happy with a translation of the qubes manager and of application names in the qubes menu (e.g. "document viewer"). That is all my wife is going to see once I set her up a qubes machine. Of course it is horrible to have an OS which is a mixture of two languages. But translating the bits you deal with most often would aid usability tremendously, wouldn't it? Olaf -- You received this message because you are subscribed to the Google Groups "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/d1e6a5294fdf05ca6de0adbc64dc00c0413d9473.camel%40aatal-apotheke.de.
Solved: [qubes-users] external CD writer
On Sat, 2020-05-02 at 09:44 +0200, dhorf-hfref.4a288...@hashmail.org wrote: > On Sat, May 02, 2020 at 01:23:53AM +0200, Olaf Klinke wrote: > > just lacking the knowledge how different writing to a CD is from > > reading from CD, on the hardware level. Is there more to burning a > > CD > > than a single block special device? > > try attaching it as a USB-device instead of a block device. > meaning "qvm-usb instead of qvm-block". Thanks a lot, that might be the bit I was missing. Unfortunately qvm- device does not seem to list any devices that are not attached to a VM, so I have difficulties identifying the right name to use. When I attach the drive to , `qvm-device block list --all` yields dom0:sr0 SDRW-08U7M () (read-only=yes, frontend-dev=xvdi) After detaching, then trying `qvm-device usb attach --verbose dom0:sr0` yields qvm-device: error: backend vm 'dom0' doesn't expose device 'sr0' I presume dom0 did not recognize the drive as a USB device and hence refuses to attach as such? `qvm-usb` yields the empty list. The usb-devices documentation recommends (or rather, lists as option) to attach the PCI USB controller holding the external drive to a qube. Following the procedure indeed results in brasero recognizing the drive as writer. Thanks! The only remaining question is: Did I buy a shitty drive or will any external CD writer behave this way? Olaf -- You received this message because you are subscribed to the Google Groups "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/8612f0f5b9cd8b2ad91264ed2438d56eb485ede7.camel%40aatal-apotheke.de.
Re: [qubes-users] Hallo, wer von der Qubes Gruppe spricht hier deutsch? Bitte melde dich!
On Sat, 2020-05-02 at 16:41 +0100, unman wrote: > On Sat, May 02, 2020 at 08:03:29AM -0700, Caroline Villinger wrote: > > > > > > Hallo, > > > > > > > > wer von der Qubes Gruppe spricht hier deutsch? > > > > > > > > Bitte melde dich! > > > > > > > > Gibt es auch in Deutschland eine Qubes Forum, denn ich m??chte von > > Windows > > 10 wegkommen und in Qubes einsteigen, jedoch spreche ich > > haupts??chlich > > deutsch! > > > > Gibt es in Deutschland auch eine Qubes Veranstaltung? > > > > Wenn ja, wo ist was geplant? > > > > > > > > Sorry to reply in English. I'm sure the German speakers here will > come > in. > > There's no problem with posting to this list in German, and there are > German speakers here. > Bear in mind that many list users *don't* speak German so it would be > helpful to post a summary in English if possible, if a problem has > been > raised and solved. > > Stay Safe > By the way, is there an i18n effort for Qubes? The dom0 menu does not seem to have any settings regarding language. I can not find anything related on github. If there is an i18n effort I'd like to help out. If no, how would one go about it? Olaf -- You received this message because you are subscribed to the Google Groups "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/879913270f5313347b00faccdbb4e6923ecba507.camel%40aatal-apotheke.de.
Re: [qubes-users] Re: Fedora 30 approaching EOL, Fedora 31 TemplateVM available, Fedora 32 TemplateVM in testing
On Fri, 2020-05-01 at 21:24 -0700, seshu wrote: > @Miguel thanks! > > and thanks to everyone who provided feedback, this was really > educational > for me. I'm not quite a qubes newbie, but I'm not an expert either. > > The idea from Brend was too sophisticated for me and so I was nervous > about > it. I decided to go with Miguel's approach and that was great. One > change > though. The qvm-stop is now qvm-shutdown, so the instructions I > needed to > use are: > > $ qvm-shutdown --wait sys-usb; \ > qvm-prefs sys-usb template fedora-31; \ > qvm-start sys-usb > > it all work quick and painlessly. This really should be added to the > instructions for updating a templateVM. I'll see if I can add that > into > the documentation. > > Thanks again everyone! > That's good to know. I shall complete this into a script that reverts the change if anything goes wrong. Sven wrote: > So make sure to remove those from your grub/EFI config before > rebooting! > The USB qube will work anyway but if it's not running dom0 will have > USB. If you skip this step you won't be able to control your computer > after reboot. > > We have a tragic case of this every other month in this list. Hearing this, I will postpone following dhorf's advice to create a sys- usb until I am more familiar with the inner workings of Qubes OS. If it was really unrisky and straightforward scripting, why did the Qubes OS installer not offer this choice, let alone just do it? Olaf -- You received this message because you are subscribed to the Google Groups "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/5ae8793a6804f944bd190bde45dcdc7be955.camel%40aatal-apotheke.de.
[qubes-users] external CD writer
(Apologies for pestering this list with another newbie question.) So I have this external DVD-RW drive (Asus SDRW-08U7M-U to be specific). On my Debian stretch laptop, plugging in the USB drive creates /dev/sr0 as well as several symlinks to it, e.g. /dev/cdrw, /dev/dvd etc. Plugging the drive into my Qubes desktop, I get notified of the availability of this drive and can attach /dev/sr0 to a Debian buster AppVM qube as /dev/xvdi. I can mount /dev/xvdi and read data from a CD allright. However, in contrast to my Debian laptop, brasero does not recognize the drive as a writer, not even when I create the same /dev/cdrw symlink. In addition to that, both commands dvd+rw-mediainfo /dev/xvdi cd-info -C /dev/xvdi exit with an error (details below). Thus it seems that some crucial bit did not get forwarded to/is not installed in the AppVM. Probably I'm just lacking the knowledge how different writing to a CD is from reading from CD, on the hardware level. Is there more to burning a CD than a single block special device? Any hints welcome. Olaf # dvd+rw-mediainfo /dev/xvdi :-( unable to INQUIRY: Invalid argument # cd-info -C /dev/xvdi cd-info version 2.0.0 x86_64-pc-linux-gnu Copyright (c) 2003-2005, 2007-2008, 2011-2015, 2017 R. Bernstein This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. CD location : /dev/xvdi CD driver name: GNU/Linux access mode: IOCTL Error in getting drive hardware properties Error in getting drive reading properties Error in getting drive writing properties __ Disc mode is listed as: Error in getting information ++ WARN: error in ioctl CDROMREADTOCHDR: Invalid argument -- You received this message because you are subscribed to the Google Groups "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/707446f665bd912823c2bdf29254087c019c40e0.camel%40aatal-apotheke.de.
Re: [qubes-users] Re: Fedora 30 approaching EOL, Fedora 31 TemplateVM available, Fedora 32 TemplateVM in testing
On Fri, 2020-05-01 at 18:22 +0100, Miguel Barbosa Gonçalves wrote:
> On 2020-05-01 17:48, brendan.h...@gmail.com wrote:
> > On Friday, May 1, 2020 at 12:39:54 AM UTC-4, seshu wrote:
> >
> > One question that just occured to me about upgrading the
> > template
> > VM's. Many of the comments and posts in this forum are assuming
> > Qubes is installed on a laptop. I have it installed on a
> > desktop,
> > and my keyboard / mouse uses sys-usb. I need to have this appVM
> > running to use the peripheral obviously. But, since the appVM
> > is
> > running, I can't update the templateVM?
>
> Hi!
>
> Before I had an additional USB controller for my keyboard and mouse,
> which by the way is a great idea as good PS/2 devices are are to
> find
> new, I used the following commands in dom0
>
> $ qvm-stop --wait sys-usb; \
> qvm-prefs sys-usb template fedora-31; \
> qvm-start sys-usb
>
> This stops the sys-usb qube, changes the template and starts it
> again.
>
> Be careful and do not make any mistakes because if the sys-usb qube
> does
> not start you might be locked out.
>
> Hope this helps.
>
> Cheers,
> Miguel
>
I am on a desktop, too, and would not know where another USB controller
should be on the machine, whence Brendan's suggestions are not feasible
for me. I take it the above commands replace the template rather than
upgrading the same template? I think swapping out the templates might
be a safer route for a qubes-newbie like me.
I do not have a sys-usb, since I installed Qubes OS while using a USB
keyboard. Which domain are my USB devices attached to? The Qubes
documentation is not explicit about that, it only says removing the
sys-usb qube will attach the devices directly to dom0. Is that the way
Qubes configures itself when installing without PS/2 keyboard?
Is it possible to amend the above commands with an automatic revert?
I'm thinking of the way one changes display settings in Windows. After
a change, a diaglogue box is presented asking whether you want to keep
the new settings. If the user does not acknowledge in a few seconds,
the old state is restored. Could the following work?
Thanks
Olaf
#!/bin/bash
qvm-stop --wait $QUBE_WITH_USB
qvm-prefs $QUBE_WITH_USB template fedora-${NEW_VERSION}
qvm-start $QUBE_WITH_USB
echo "hit Ctrl-C to keep the new fedora $NEW_VERSION"
sleep 10
# if keyboard still works, the user will be able to interrupt here.
qvm-stop --wait $QUBE_WITH_USB
qvm-prefs $QUBE_WITH_USB template
fedora-${OLD_VERSION}
qvm-start $QUBE_WITH_USB
echo "failed to upgrade to fedora-${NEW_VERSION}"
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/13e3b003ed5f43eab6e7ba843eb98f0d6f7d34e7.camel%40aatal-apotheke.de.
Re: [qubes-users] qubes AppVM nameservers
On Sun, 2020-04-26 at 22:15 +0200, dhorf-hfref.4a288...@hashmail.org
wrote:
> On Sun, Apr 26, 2020 at 09:17:10PM +0200, Olaf Klinke wrote:
> > it seems that some iptables rules are set on VM boot that redirect
> > port
> > 53 requests, but I can't get iptables inside the AppVM to divulge
> > these
>
> those rules should exist in your external netvm (sys-net), and point
> to
> the "real" nameservers as received by dhcp (or configured via
> netmanager).
>
> that way the individual appvms do not need to know about that part
> of external configuration.
>
> i have seen the rules get "lost" (actualy: point to useless IPs) on
> some kinds of external reconfiguration events.
> (like hard restarting the netvm of a vpn-vm)
>
>
Indeed.
root@sys-net# /sbin/iptables -t nat -S PR-QBS
Lists re-directions from 10.139.1.{1,2} to $MYROUTER
In sys-firewall the translation is trivial from 10.139.1.1 to
10.139.1.1 and likewise for the other nameserver.
So the reason for the absence of any rules in the AppVM presumably is
that all traffic is handled by sys-firewall? That would mean if DNS
lookup is wonky again, I'd start looking at sys-firewall rules.
Thanks for clarification.
Olaf
--
You received this message because you are subscribed to the Google Groups
"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/bcb88b23438f103fece367f208a90e9b1553cc21.camel%40aatal-apotheke.de.
[qubes-users] qubes AppVM nameservers
Dear Qubes users, today DNS lookup temporarily failed in my Debian AppVMs attached to sys-firewall. I took a look at /etc/resolv.conf and it lists the nameservers 10.139.1.1 10.139.1.2 Qubes Manager shows no VMs with that address, sys-firewall has 10.137.0.6 and sys-net has 10.137.0.5. Editing /etc/resolv.conf to use external nameservers restored DNS lookup, but that is certainly not how it is supposed to be. After a fedora-30 update and re-start of the physical machine, DNS lookup works again, even with the seemingly non-existent nameserver. sys-net lists my DSL router as nameserver. Name resolution worked on other devices attached to the router. What is going on here? (I already looked at the networking documentation at qubes-os.org.) Reading /usr/lib/qubes/qubes-setup-dnat-to-ns it seems that some iptables rules are set on VM boot that redirect port 53 requests, but I can't get iptables inside the AppVM to divulge these rules. Hence I wonder how to debug this if the issue should happen again. Thanks, Olaf -- You received this message because you are subscribed to the Google Groups "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/438b854d30facc493a4a7be72519a64c185e8715.camel%40aatal-apotheke.de.
