Re: [qubes-users] Dual boot and two swaps?
On 25/02/17 02:33, Oleg Artemiev wrote: Say I've one enrypted swap and one not from other linux. Would Qubes ignore unencrupted swap from other distribution or I should make it to? If so - how do I? as far as i understand it, swap is a partition with the file-system swap and mounted as swap. so if you do not mount the unencrypted swap as qubes swap, everything should work. you may need to use manual partitioning during setup. if dual-booting you should use anti evil maid (see: qubes doc). -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7dbec4ef-a98f-d15a-13ac-3ab874b790ce%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Two qubes multinoot
On 25/02/17 04:14, Oleg Artemiev wrote: Hi. If I want to run VMs from one Qubes in another why would you even dualboot two qubesversions? would it be possible to have different coloring for the same VM in different Qubes OS instances? here the questions is, what files you would share? i am not sure, where the label is saved, but if you only share the images, it should work (but i am still not sure what you are trying to do). Is this possible from a VM to attack Dom0 by altering VM image files or this is just files and adversary able to rewrite image in one Qubes has no option to appear outside VM when it is loaded in another Qubes OS instance? a vm can always only write data inside of an image. if a vm can write data in dom0, your system is owned and you need something as aem to protect the other instance. but even with aem, i think one qubes dom0 A could compromise the other dom0 B, since A can somehow read and write files of B. but if you assume both dom0 are secure, i don't see a problem. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a92d6504-05e1-a166-23c3-f306f72b9271%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] strange error when installing pycairo on fedora minimal
hi. i want to install terminator in my vm. since the terminator package does not install everything correctly (pycairo is not installed), i need to install pycairo manually. but this does not work, since dnf somehow ties to install a different package... $ sudo dnf install pycairo Package qubes-template-minimal-stub-1.1-1.fc23.noarch is already installeDependencies resolved. Nothing to do. Sending application list and icons to dom0 Complete! i tried this on two new clones of fedora 24 min, only installed sudo and updated all packages. this seems very strange, since the package seems to be for f23. strangely enough i can install pycairo-devel or anything else i tied after this. executing `dnf list installed qubes-*` gives me (on fedora minimal): Installed Packages qubes-core-vm.x86_643.2.15-1.fc24 @qubes-vm-r3.2-current qubes-core-vm-systemd.x86_643.2.15-1.fc24 @qubes-vm-r3.2-current qubes-db.x86_64 3.2.3-1.fc24 @qubes-builder-vm-r3.2-current-testing qubes-db-libs.x86_643.2.3-1.fc24 @qubes-builder-vm-r3.2-current-testing qubes-db-vm.x86_64 3.2.3-1.fc24 @qubes-builder-vm-r3.2-current-testing qubes-gui-vm.x86_64 3.2.9-1.fc24 @qubes-vm-r3.2-current qubes-libvchan-xen.x86_64 3.2.0-1.fc24 @qubes-builder-vm-r3.2-current-testing qubes-template-minimal-stub.noarch 1.1-1.fc23@@commandline qubes-utils.x86_64 3.2.3-1.fc24 @qubes-builder-vm-r3.2-current-testing qubes-utils-libs.x86_64 3.2.3-1.fc24 @qubes-builder-vm-r3.2-current-testing qubes-template-minimal-stub is the only package for fedora 23 so my question is: does someone else have this bug? is there a problem with qubes-template-minimal-stub being a fc23 version? (maybe the version was simply not updated) how can i install pycairo? - John -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3eec3788-bff5-75c4-7afa-5dbe42ab4a4d%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] program icons for fedora-minimal
hi. if i use templates based on fedora minimal, the start menu entries only have a lock as an icon. vms based on the normal fedora template have icons. how can i get icons for my fedora minimal vms? - john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bda98578-d046-a406-7b9c-3fd51a66a9c2%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cant start the AppVM - uninstalled python-numpy.
On 13/02/17 01:31, Keld Norman wrote: Hi community :) I ran this on a standalone debian 8 appvm apt-get purge python-numpy Yes, I now know that is not the most cleaver command to run.. It resulted in the following packages got removed: python-numpy python-qwt4-qt4 qubes-core-agent gimp gpsd-clients live-usb-install python-glade2 python-matplotlib qubes-gui-agent w3af python-kivy python-gtk2 python-scipy python-pygame So now I can not boot that AppVM normally.. I can connect to it using: sudo xl console Lab from dom0's console and get a prompt (login as root) but I am missing the /rw directory and everything seems readonly (I wanted to reinstall the uninstalled packages) When i try to run apt-get install (all the packages listed above) it just fails with "Unable to write to /var/cache/apt" because /var is not there and /rw is also not there.. :/ i am not an expert in this, but did you try to `sudo mkdir -p "/var/cache/apt"`? maybe this allows you to re-install the packages. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/41f62804-a020-4120-88f2-66cb03e89986%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] using a custom salt module in top files
hi.
i wrote some custom salt module and use it for rendering in my top-file.
everything works great as long as i am only in dom0.
as soon as my stuff is run in domU (or rather its management-vm) i get errors:
when rendering:
/var/tmp/.root_62a99a_salt/running_data/var/cache/salt/minion/files/base/top.jinja
i get an error in line 77:
77: {%- load_yaml as single_top -%}
78: {% include top %}
79: {%- endload -%}
this is the place where my top file is included.
after including the file, rendering it as yaml fails.
after adding some outputs to jinja i was able to see my rendered top file.
the line it complains about is:
{'retcode': 0, '_error': 'Failed to return clean data', 'stderr': "'my.function' is
not available.", 'stdout': ''}
the original call is:
{{ salt['my.function'](yaml=yaml, grains=grains) }}
the error suggests:
when my top file is included in top.jinja, no custom salt modules are used.
this seems to be a bug.
how can i fix this?
i could add some wrapper around it and do rendering for domu using jinja, but
this is kind of cumbersome.
this is also only possible since my function only does very little in domu.
furthermore this would prevent me from doing more complex stuff in domu in the
future (currently it is not planned, but maybe i want to do such stuff in the
future).
so i am interested in a way to fix the rendering (so it correctly uses the
custom module).
-john
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/657da085-57eb-e816-13d5-fea8e13c8050%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: traveling - best practice
On 10/02/17 11:53, '0xDEADBEEF00' via qubes-users wrote: Interesting topic... I would like to here more about how people handle this. On my side, I'would never work on sensitive information in such a situation. To make just some surfing in public place, my laptop is installed with a standard w10 that I use only to check a generic mailbox with on sensitive information, do some nonsensitive work and surf. By the way, the boot sequence of my laptop is set to boot this partition by default with no menu or prompt of any kind. If I want to boot into qubes, I have to do it manually by interupting the boot sequence. This also serves as a decoy, if I'm forced to boot my laptop when passing borders or so. Best, 0xdeadbeef dual booting opens a whole new attack surface. is there a way to deal with this? the other os may not be able to read/modify qubes due to encryption, but it can write something malicious on the disk (e.g. some loader running before 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9dca7684-fa81-ecd3-bc34-938db60ed188%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ubuntu template
Unman can you make a template rpm Ubuntu and put it on https://ftp.qubes-os.org/repo/yum/r3.2/templates-community/rpm/ ?:) i also would prefer this option, but it seems it is not possible due to legal issues. see: https://www.qubes-os.org/doc/templates/ubuntu/ maybe we could convince canonical to allow this case, but somehow i doubt they will allow 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/45fa00a2-15b7-61e1-06ea-8469de3f0665%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] traveling - best practice
On 07/02/17 14:09, haaber wrote: Hello, I wonder how you behave when traveling, for example in places with cameras all around. I feel uncomfortable to enter my passwords in such situations. Of course I can simply not turn my computer on. But sometimes you have several hours in an airport .. I thought about 3 options. 0) Change all (disk / user) pwd before & after traveling (how do I change the disk pwd?). i already had the same question. I think a simple way to do this from dom0 would be nice (simple = one terminal call and not digging around in some config files) 1) Pull out my tails usbkey and surf with that? do you always allow booting from usb? (in my case the bios pw is required and i would not want to enter it) 2) maybe it woud be nice to have an additional "single cube" usr/password : when using this user name, one would get a single disposable untrusted VM, no dom0 acces, no USB, and so forth. Is that feasable / reasonable? i think this would be a nice feature -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5ca9cb6c-2f24-3bdb-14ff-377141036562%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Having trouble configuring VMs with Salt / qubesctl
On 07/02/17 00:01, Joe Ruether wrote:
Hello! I am using Qubes 3.2 and I am attempting to automate the configuration
of my VMs using the Salt / qubesctl management stack.
I am very new to salt, but I have been experimenting and I think I understand
how it works. I have written some state files to configure dom0 and I haven't
had any problems with those.
The problem I am running into is that whenever I try to do anything at all with
a VM, it seems that the qubesctl process just hangs. I've let it run overnight
just to see, and it definitely isn't doing anything. I also don't know how to
make it more verbose so I can debug the issue.
Here are the contents of my top file, /srv/salt/custom/setup.top:
base:
dom0:
- custom.template.fedora-24
fedora-24:
- custom.up-to-date
---
The goal I am trying to accomplish is to install the fedora-24 template, then
update the packages on it. Here is my custom.template.fedora-24.sls:
#!pyobjects
Pkg.installed("qubes-template-fedora-24")
Qvm.prefs("fedora-24", label="black", netvm="sys-firewall")
---
And here is my custom.up-to-date.sls:
#!pyobjects
system = grains("id")
#Pkg.uptodate(system, refresh=True)
Test.nop(system)
---
Notice how I commented out the uptodate function and replaced it with a nop,
with the intention of just getting it to return true.
When I run the following command, dom0 successfully installs and configures the
fedora-24 template, and the fedora-24 template is started, but after that, it
freezes:
qubesctl --all state.highstate
CTRL-C doesn't give me back a prompt, instead I get errors regarding pool workers. I end
up using CTRL-Z and issuing a "killall -9 qubesctl" to make it stop.
I don't know how to get more information on the VM to discover what is going
wrong. I have (manually) fully updated dom0 and restarted the physical
computer. Any tips would be much appreciated. Thank you!
i never had this kind of problem and can't really help you with your sls-files,
since i am only used to the yaml + jinja form.
but you could take a look at the documentation for debugging salt:
https://www.qubes-os.org/doc/salt/#debugging
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/ab931f07-3e2f-bada-759e-1a00ebc950b5%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Backup VMs" does not backup salt configuration
On 05/02/17 23:59, john.david.r.smith wrote:
On 05/02/17 00:06, Oleg Artemiev wrote:
Hi.
On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith
<john.david.r.sm...@openmailbox.org> wrote:
On 01/02/17 21:30, qu...@posteo.de wrote:
I have now nearly a complete salt configuration for all my templates so I
do not need to backup them anymore and save a lot of space by this.
So I have ran a backup including dom0 and realized that the salt
configuration ("/srv/salt") does not seem to be included because it is much
bigger than the MB listed for dom0.
Is there a way to back it up right now with this method or do I manually
have to copy everything outside of dom0?
Thx in advance
i put my files in ~/salt and symlinked them to /srv/salt
then backups should work
Could you point to source for more information on your work?
Backups work slow (disk/network bottlenecks) & I'm also interested to
backup less.
i started to extend the salt documentation and just added an pull-request.
you can find my repo of the doc here:
https://github.com/john-david-r-smith/qubes-doc/blob/salt-doc/configuration/salt.md
here the correct link (i failed to push on my branch...):
https://github.com/john-david-r-smith/qubes-doc/blob/master/configuration/salt.md
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/d90a0278-4868-264f-8abf-2f8232788037%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Backup VMs" does not backup salt configuration
On 05/02/17 00:06, Oleg Artemiev wrote:
Hi.
On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith
<john.david.r.sm...@openmailbox.org> wrote:
On 01/02/17 21:30, qu...@posteo.de wrote:
I have now nearly a complete salt configuration for all my templates so I
do not need to backup them anymore and save a lot of space by this.
So I have ran a backup including dom0 and realized that the salt
configuration ("/srv/salt") does not seem to be included because it is much
bigger than the MB listed for dom0.
Is there a way to back it up right now with this method or do I manually
have to copy everything outside of dom0?
Thx in advance
i put my files in ~/salt and symlinked them to /srv/salt
then backups should work
Could you point to source for more information on your work?
Backups work slow (disk/network bottlenecks) & I'm also interested to
backup less.
i started to extend the salt documentation and just added an pull-request.
you can find my repo of the doc here:
https://github.com/john-david-r-smith/qubes-doc/blob/salt-doc/configuration/salt.md
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/2505d2c9-ff11-08e0-b815-bf768464b65a%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Disposable VMs
On 04/02/17 18:42, Loren Rogers wrote: Hi all, I'm confused about running disposable VMs - if I open a browser or file viewer, then want to open a terminal for the same VM, how could I do this? (E.g. I want to view an untrusted file, then make some edits.) right click the dispvm in the qubes manager. select run command. enter xterm or whatever you want to run or user (in dom0) qvm-run DISPVM_NAME xterm Is there a way to configure the default disposable VM in the Qubes menu? I see that disposable VMs can be configured for individual domains, but I can't find where the generic one is. Also, is it possible to specify a different template for disposable machines? Say I'm running something based on the default fedora-23, and I want to open a document from my work VM, which uses that template. But I want to open it with my fedora-23-custom template as a disposable VM. (E.g. running a video in VLC that has untrustworthy components.) Is this doable? currently you can only have one dispvm. if you want, you can set the template as default for dispvms (qvm-create-default-dvm) -john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a56fa765-2503-8f2a-2f05-6ba87e5cbb72%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-run --dispvm in dom0
hi. is there some way to launch a dispvm from dom0 and execute a command (just like `qvm-run --dispvm` in domu) or do i need to create a temporary vm? -john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cc3901b7-7041-f6f0-7860-e11b50790fb4%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Backup VMs" does not backup salt configuration
On 01/02/17 21:30, qu...@posteo.de wrote:
Hi,
I have now nearly a complete salt configuration for all my templates so I do
not need to backup them anymore and save a lot of space by this.
So I have ran a backup including dom0 and realized that the salt configuration
("/srv/salt") does not seem to be included because it is much bigger than the
MB listed for dom0.
Is there a way to back it up right now with this method or do I manually have
to copy everything outside of dom0?
Thx in advance
i put my files in ~/salt and symlinked them to /srv/salt
then backups should 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/ba5ec9f2-6b8c-7bf0-570d-7c3e6aac5c84%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Wine/PlayOnLinux Best Practices
On 31/01/17 22:24, mojosam wrote: it does protect you from user errors. e.g.: you have some malicious pdf in a vm. if you have noting to open the pdf, you can't accidentally open it and corrupt your vm. Isn't that the concept behind "attack surface"? If the code is there, something malicious might have the ability to call it. I think there was malware that was recently discovered that could exploit the floppy disk controller in either VMware or VirtualBox. but if there is something malicious able to call it, the malicious piece of code could download play on linux and then exploit the error. the case is: - there is something malicious - it can execute code hence it can install everything it wants to and exploit it (but that is not even necessary, since it only needs remote code execution to do anything it wants to do) in this case we already executed something and caused the malicious code to become active (e.g. opened it with a program) the case i mentioned was: - there is something containing malicious code (e.g. a pdf) - the code can't activate, since no piece of software parses this code the attack surface is created by the code you execute rather the code that is on the system. this is the case, because you only need remote code execution to own a qubes vm. (instead of remote code execution + privacy escalation) the only advantage of not installing software is: you can't be able to accidentally execute it and activate some malicious code (but here your action would extend the attack surface) at least this is my understanding of the situation. The bigger practical concern is that PlayOnLinux expanded my template by 800 MB. Is all of that cruft duplicated on the hard drive for every VM, or is it just accessed from the template as needed when the VM is activated? this depends on the location that stuff is stored at. if it is somewhere on /rw (e.g. /home/user) each cloned vm will have a duplicate. if play on linux downloads the stuff after its first execution, you can simply only execute it in vms using play on linux. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/98fffab0-8e22-061c-ddb5-e10afa59de4c%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Right Way to Setup your VPN to prevent Leaks ?
On 31/01/17 19:38, ulabunga wrote: My Setup proxy vm + airvpn in network manager ,TCP-53 -> appvm x importing airvpn VPN configuration files (TCP-53) in my proxy vm network manager and select this 'AirVpn' proxyvm in my netvm settings for all my fedora/debain appvm's. Is there any better more secure way (not tor) to setup my internet security? I noticed having DNS leaks the first 5 seconds after Im connected to a new server.. that is a known problem. you can add some iptables rules to fix that. there is a guide in the doc: https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts look at the iptables section -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b8c08d11-21f7-b0d9-55e7-04ae85bc162a%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Wine/PlayOnLinux Best Practices
Since this is in my regular Fedora 24 template, won't this codebase be included in every app VM I run, whether I'm running PlayOnLinux in that app VM or not? yes Presumably none of that code would be running, so there should be no problem (at least i can't see any problems) but it would still be accessible to malware that wanted to call it. for this the malware does need remote code execution. if it has remote code execution it simply can call sudo dnf install -y playonlinux it also could download anything and simply execute it as root. (root has no password) so not having something installed does not protect you if you would not call it anyways. it does protect you from user errors. e.g.: you have some malicious pdf in a vm. if you have noting to open the pdf, you can't accidentally open it and corrupt your vm. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/af70957f-600e-8bbc-dd72-c240d3972e4b%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Minimal VM requirements for Salt configuration are not documented
On 20/01/17 14:13, john.david.r.smith wrote: On 20/01/17 13:18, qu...@posteo.de wrote: Hi John, On 20.01.2017 10:26, john.david.r.smith wrote: looks like my problem i posted here: https://groups.google.com/d/msg/qubes-users/C1tJV4Ykgr8/5H09IT06CQAJ i did not try it again since i had this problem. missing in min are sudo and file (but after this i still get problems) many thx for the reply. You are right, some issues overlap. I have tried installing sudo but not file. Installing also the later fixes the issue of the default template, so you can use the extended Minimal as default template with these changes and do not get the error 127 for standard templates. But applying salt on minimals vms with all the mentioned packages plus sudo and file still results in the exit code 20. How can I debug this further. What commands are run on the disposble vms so I can see more output? Thx in advance well that is the part i am currently at (as i wrote, i did not try again after Marek answered. Marek wrote a few tricks on debugging this problem. (ctrl+z when the target vm is started etc. (you can look it up in the linked thread)) i will probably try again this weekend and will post any results i get. in case you manage to fix this, tell me! ;) concerning a tutorial: i probably will write a more verbose tutorial if i got all my stuff fixed. -john problem solved (details posted in other thread). you need to install in fed24 minimal the sudo package and delete the left over files in the ~/QubesIncomming folder (they screw you over) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f9ace7a7-6d8c-22bb-bb70-0e26fb49728c%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] a few things about salt
Did you really need tinyproxy in the target template? It should be needed only in your netvm... Or are you saying that tinyproxy was missing in your netvm? it was red in my fed24 minimal journalctl. after i installed it, it went away (currently most things i am doing are kind of blind since i never done any sysadmin stuff before qubes and don't really know what i am doing) i tried it again without the package and it worked. this time i only needed to install sudo. (file was not necessary) now it still does not work... the journalctl contains no really useful information (at least noting i can understand as something useful the only thing looking like some kind of error was (the test template is a clone of minimal and is called a): Jan 22 00:25:20 a qubes.VMShell-disp-mgmt-a[1192]: WARNING: Unable to locate current thin version: /var/tmp/.root_62a99a_salt/version. Jan 22 00:25:22 a qubes.VMShell-disp-mgmt-a[1324]: WARNING: Unable to locate current thin version: /var/tmp/.root_62a99a_salt/version. the folder '/var/tmp/.root_62a99a_salt' does exist, but it is empty Have you cleaned QubesIncoming directory after failed attempt? no i did not. and finally it works! This suggests you have not: Jan 22 00:25:21 a qrexec-agent[465]: executed root:QUBESRPC qubes.Filecopy disp-mgmt-a pid 1254 (...) Jan 22 00:25:21 a qrexec-agent[465]: pid 1254 exited with 17 17 is EEXIST (File exists). Looking at all the troubles this caused, we should fix it somehow - either automatically remove before uploading the file (as in case of failure, it isn't removed after that attempt), or upload a file with a unique name. The later will be safer (do not remove any file without explicit user consent). that would be good (and i would also be for using some unique id (e.g. seconds since epoch) since i am no fan of stuff deleting files) also it would be nice if the min template would contain the sudo package (or rather all packages required of a minion to be configured via salt), since other users will probably run in the same problems (at least one already has) especially since salt is supposed to become the default config tool for vms. (at least this is my current goal) thanks for all your help! tomorrow i will try to get the last things running and after that i will start writing a guide. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4cfe4447-b284-b1c7-7b1c-9a3f3f534d8a%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] a few things about salt
i am currently looking whether i can do the same in a top file (but i doubt
it, since there is no templating in top files)
And the last sentence is exactly the reason why it's tricky to have it
in one place.
well it seems we were totally wrong.
you can put jinja code in your top file.
i already wrote some python module to be able to manage everything from my top
file.
after i tested it some more, i will post it here.
(if i ever manage to fix all my salt issues i will probably extend the salt
section in the documentation, put that module there and document everything i
learned about salt and jinja templates.)
8)
is there some way to execute some dom0 scripts after configuration of domu?
(e.g. trim-template)
Currently no.
do you plan to add something like this?
We don't have such plans, but will accept a patch for this ;)
how are the minions run?
via a salt statement in dom0?
if not it should be possible to do this (just run the current script via
cmd.run).
if a state dispatches all minions we could use requires to order states after
domu salt configuration.
The actual error is in the middle of this stack trace:
log.error('ERROR: Failure deploying thin, retrying:
(there is unrelated salt bug in logging code here...)
And some more helpful message will be also in journalctl of target VM
(tmp-base-f24). This is where I've found missing file and sudo.
ok, i tried around some more.
it seems i was missing tinyproxy as well.
now it still does not work...
the journalctl contains no really useful information (at least noting i can
understand as something useful
the only thing looking like some kind of error was (the test template is a
clone of minimal and is called a):
Jan 22 00:25:20 a qubes.VMShell-disp-mgmt-a[1192]: WARNING: Unable to locate
current thin version: /var/tmp/.root_62a99a_salt/version.
Jan 22 00:25:22 a qubes.VMShell-disp-mgmt-a[1324]: WARNING: Unable to locate
current thin version: /var/tmp/.root_62a99a_salt/version.
the folder '/var/tmp/.root_62a99a_salt' does exist, but it is empty
the journalctl log is attached. (maybe someone with more knowledge can make
sense of it)
does the salt-ssh command run some script on the minion i can execute manually
line for line so i can (maybe) find the source of the error? (i could try to
manually execute all this python code, but this would be very cumbersome and
hard to understand)
how much of this execution differs from the default salt? (if nothing really
differs i will ask on the salt ml)
@Marek:
were you able to configure a fresh fedora-24-minimal template at the end of
your debugging?
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/ab8158a6-3d58-f913-960d-41e2ac2a4958%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
-- Logs begin at Sat 2017-01-21 23:33:21 CET, end at Sun 2017-01-22 00:27:00
CET. --
Jan 22 00:25:20 a qrexec-agent[465]: executed root:QUBESRPC qubes.VMShell
disp-mgmt-a pid 1163
Jan 22 00:25:20 a audit[1163]: USER_AUTH pid=1163 uid=0 auid=4294967295
ses=4294967295 msg='op=PAM:authentication grantors=pam_rootok acct="root"
exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
Jan 22 00:25:20 a audit[1163]: USER_ACCT pid=1163 uid=0 auid=4294967295
ses=4294967295 msg='op=PAM:accounting grantors=pam_succeed_if acct="root"
exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
Jan 22 00:25:20 a su[1163]: (to root) root on none
Jan 22 00:25:20 a audit[1163]: CRED_ACQ pid=1163 uid=0 auid=4294967295
ses=4294967295 msg='op=PAM:setcred grantors=pam_rootok acct="root"
exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
Jan 22 00:25:20 a kernel: audit_printk_skb: 3 callbacks suppressed
Jan 22 00:25:20 a kernel: audit: type=1100 audit(1485041120.084:183): pid=1163
uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication
grantors=pam_rootok acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=?
res=success'
Jan 22 00:25:20 a kernel: audit: type=1101 audit(1485041120.084:184): pid=1163
uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting
grantors=pam_succeed_if acct="root" exe="/usr/bin/su" hostname=? addr=?
terminal=? res=success'
Jan 22 00:25:20 a kernel: audit: type=1103 audit(1485041120.084:185): pid=1163
uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_rootok
acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
Jan 22 00:25:20 a systemd[1]: Created slice User Slice of root.
Jan 22 00:25:20 a systemd[1]: Starting User Manager for UID 0...
Jan 22 00:25:20 a systemd[1]: Started Session c13 of user root.
Jan 22 00:25:20 a audit[1164]: USER_ACCT pid=1164
Re: [qubes-users] Minimal VM requirements for Salt configuration are not documented
On 20/01/17 13:18, qu...@posteo.de wrote: Hi John, On 20.01.2017 10:26, john.david.r.smith wrote: looks like my problem i posted here: https://groups.google.com/d/msg/qubes-users/C1tJV4Ykgr8/5H09IT06CQAJ i did not try it again since i had this problem. missing in min are sudo and file (but after this i still get problems) many thx for the reply. You are right, some issues overlap. I have tried installing sudo but not file. Installing also the later fixes the issue of the default template, so you can use the extended Minimal as default template with these changes and do not get the error 127 for standard templates. But applying salt on minimals vms with all the mentioned packages plus sudo and file still results in the exit code 20. How can I debug this further. What commands are run on the disposble vms so I can see more output? Thx in advance well that is the part i am currently at (as i wrote, i did not try again after Marek answered. Marek wrote a few tricks on debugging this problem. (ctrl+z when the target vm is started etc. (you can look it up in the linked thread)) i will probably try again this weekend and will post any results i get. in case you manage to fix this, tell me! ;) concerning a tutorial: i probably will write a more verbose tutorial if i got all my stuff fixed. -john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2dd8e092-d208-0b51-18d4-5f299eef6b74%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] a few things about salt
1) even when some states fail for some vm, the cli tool displays ok. it would be better, if it displayed error in case of an error (some errors are displayed). Can you provide example error which wasn't detected? Regardless of the result, output is logged to /var/log/qubes/mgmt-*.log in dom0. i somehow fail to reproduce the case. (i just noticed it when playing around with salt) there were some states failed inside domu (i think some package installation) i will try to reproduce it later. 5) are there plans to add some functionality to the interface? Yes, "qvm" module will be extended for new features in Qubes 4.0. Is it what you've asked about? yeah. the question was just about any planned additions. I think there is currently no sane way to setup global defaults (other than cmd.run: qubes-prefs ...). So, we'll work on that too. nice 6) currently i really don't like the way the configuration works. i have a top file where i execute some states for dom0 these states create and configure my vms. then in some top files i choose some vms and configure them again (but this time it is some config i am doing in the domu). so it kind of looks like this: top.top - base: dom0: - create-cfg-vm1 vm1: - some-cfg-in-domu now i have two layers of configuration (in top and sls). for some config stuff i have to change a sls and for other i have to change the top is there a plan to change this? e.g. some kind of virtual minions? i would like to write something like this: top.top - base: dom0: - copy-sequence.Strg-Alt-Shift-C vm1: - create#this affects dom0 - color.red #this affects dom0 - netvm.sys-tor #this affects dom0 - mail #this affects domU then i could see all my domU config in the top file. i currently hacked something but this only works in a sls file and for dom0 config (but has this style of syntax) i am currently looking whether i can do the same in a top file (but i doubt it, since there is no templating in top files) And the last sentence is exactly the reason why it's tricky to have it in one place. Rendering sls files (may) require getting data (grains) from target system and we don't want to parse that data from VM in dom0. To limit attack surface. So, we can't render sls for VMs in dom0, we need to decide what goes where at 'top' files level. I think the only think that can be improved here, is some "automatic" creation of VMs mentioned in top file - something like you've described above. But it's tricky to do it, while keeping flexibility of salt... Using valid salt syntax like yours, to achieve different effect looks like asking for troubles. If going that way, IMO it would be better to have something that isn't valid salt syntax here and have a pre-processor script to create actual salt configuration. i am currently working at something like this: i have a top file activating a dom0 sls in this sls i do dom0 config, create vms and configure them (dom0 config AND domU config). all domU config is used to generate a generated.top file activating the correct states for the correct minions. then everything is in one file (not the top file, but this sls file has the function of a top file) the disadvantage would be that i always need to run dom0 to generate up to date files for my minions. (but in my opinion the advantages beat the disadvantages) how is the order of execution? will dom0 always be executed before any domU is started? Yes. In particular you can create VMs using states for dom0, just to have them configured a moment later using states for VM. when are the files for domU read? after dom0 is configured? (then i could write state files during dom0 configuration) Yes, those files are loaded just before configuring VM. i noticed that, but it could have been possible you do something like this (maybe because salt does things like this): a) copy all files to some cache b) run dom0 (using the files from the cache) c) run domU (using the files from the cache) in this case i would not be able to generate files in b to use in c 8) is there some way to execute some dom0 scripts after configuration of domu? (e.g. trim-template) Currently no. do you plan to add something like this? 9) the fedora-24-min template can't really be configured with salt. there is the package file missing. after i installed the package i still got an error: "Target 'fedora-24-min' did not return any data, probably due to an error. exit code 20" The important thing is what is your default template - it is used for that intermediate VM from where target VMs are configured. Is it also fedora-24-min? salt-ssh requirements in the target VM are really minimal - I think any shell + python should be enough. For me it works, but it's possible that my minimal template is no longer such minimal... Ok, tried on fresh minimal template and found the problem: sudo So, packages needs to be installed: - file
[qubes-users] qvm-ls
hi.
two questions about qvm-ls
1)
qvm-ls displays ip, ip back an gateway/DNS.
what is ip back?
2)
how does the --raw-data flag work?
can someone post an example?
i tried things like
qvm-ls --raw-data ip sys-tor
but i always end up with a traceback of qvm-ls ('line 225
fields[f]["max_width"] = len(f)')
- john
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/b6ebe2fa-779b-0e0b-bbb9-7a10a2344a92%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] question about policy permission declarations
hi. when looking at the policy permissions in '/etc/qubes-rpc/policy' i noticed the only line 'qubes.USB' contains is: $anyvm $anyvm deny why is that line there? as far as i understood it has no effect as any other declaration of the form: $anyvm deny since deny is the default action and this rule will catch any vm. (the only effect would be that all following permission declarations targeting the destination are ignored. but now i am not sure anymore.. so can someone tell me whether my understanding of the permissions is correct? -john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b5b9b15c-5b26-8cf3-6698-f55e1e0a2988%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 Dom0 no longer updating.
On 06/01/17 13:15, Opal Raava wrote: Hi all, Since about a week or so, I'm unable to update dom0 the way I used to. The VM Manager will tell me there are updates available for Dom0, and when I click 'Update VM' I see the familiar 'downloading updates' but after that the window with the updates never appears. If I run qubes-dom0-update it tells me 'No updates available' Does this perhaps have to do with fedora23/fedora24 issues? I asked on IRC and one person is having this issue as well. Is anybody else having this issue? i have the same 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/87fb2f71-98d3-0fe9-ee1c-a8be6adadad3%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Have Windows VM open and play video in Linux VM?
On 02/01/17 15:34, Jarle Thorsen wrote: As there is currently no audio support for Windows in Qubes OS: Can I use any of the Qubes windows tools to copy a video file to a Linux vm and have it start playing there? The file should only be copied to a temp directory, and not put in QubesIncomming. Which tool/syntax will let me do this? there are two ways: 1) (the better way if you can get a working setup) for sound/video you can use streaming software (i did this some time ago). you have a windows vm W and some linux vm N. you set N as netvm for W. then you use some virtual soundcard (i think i used hifi cable) and some streaming software to stream the sound to the linux vm (i can't remember what i used.) on N you receive the stream. since you can hear all audio output of a linux vm, you will hear sound from W. my setup was fiddly and had about 2 sec audio delay. (but i did not really bother to fix it, so you probably can do better) 2) again have some linux vm N as netvm of a windows vm W. then you can use public folders on W and mount the public folder on N. now you can play the video from N. i used both methods for a while (until i completely switched to linux for all my work-flows). in both cases i did not use the windows tools. if you have working windows tools, you should have a qvm-open-in-dispvm command . you could also try this command. (i am not really sure whether the windows tools contain this command) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cca362f3-9f9a-0067-995c-baf5f387564e%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] RFC: adding qubes images to the (qubes) repo
if offloading is done for isos: ship the master key with qubes and provide a convenience command to the user. this command should download (e.g. via torrent) and verify the image (a step the user can'd do wrong anymore). this command could spawn a dispvm, install torrent software, load the torrent and copy it to dom0. from there the user could qvm-copy it to the vm with the install medium. This is a different proposal, and it would be a much larger undertaking. It's certainly not something that the core Qubes devs have time to do, so it would have to be a community-developed feature. Would you like to take this project on? my current idea: 1) create a temporary download vm A 2) use wget to get the signature + iso + release signing key 4) create a temporary verify vm B 5) copy the data from A to B 6) destroy A 7) copy the qubes-master key from dom0 to B 4) set the master key to ultimate trust 5) verify the release signing key 6) check the signature 7) copy the image to dom0 8) destroy B you also could do all steps in one vm. i think this should be possible with the current tools. (i would have to look up how to do all this key management stuff via shell. i have not this much time (and am not really skilled), but what i thought about would not be that much work. if this solution is acceptable, i can give it a try. it would be in form of some bash scripts. maybe you could get other official repos to add them, too. (debian (+ubuntu), fedora and arch should reach a significant portion of the linux users) Another interesting idea. I've never heard of a distro adding a different OS's ISO as a package of their own, though. asking can't hurt. Well... why don't you ask them, then? :) some random guy is more likely to be ignored than people officially connected to a project (but i could try to ask them and link them to this thread.) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7cb32011-da34-b4a0-e9cb-e7942a6fa308%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] RFC: adding qubes images to the (qubes) repo
the problem is (as you wrote) 'supposed to be verified out-of-band'. for some less technical people, even verifying the signature is a huge step. i am a fan of providing easy accessible security and using already existing infrastructure. (in case of the dom0 repo, an ultimately trusted source). I'm weary of calling the dom0 repo an ultimately trusted source, as it implies trust in all the related infrastructure (DNS, CAs, etc.) Package managers follow a trusted objects model. Each package's signature is verified before installing, meaning trust of the repo is not required. ok, i was a bit imprecise. i meant: packages loaded and verified (via signatures) from the repo for dom0 can be considered ultimately trusted. if one of the installed packages of the dom0 repo is compromised, we have an attacker in do0 and it is game-over. so we can assume these packages are ultimately trusted. In either case however, a signing key must be distributed in such a fashion that it can be verified and, as such, Im not sure if this offers anything other than a wrapper around the signature verification step. if you distribute the key with the os and it is living in dom0, it can only be changed by someone in dom0 -> game-over so: if the key is compromised, you cant trust anything on this machine either it was somehow compromised during usage, or it was compromised from the beginning (via a compromised installation image) if the key is in dom0 and you want to verify it over a different channel, you can load it into some vm and do this there. the wrapper-function to download and check images is just convenience for a non-technical user. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e0f4abff-a9d0-a1f4-72f3-c26ae643ab19%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] RFC: adding qubes images to the (qubes) repo
this may be a source of errors for some users, or even insecure (mitm + exchanging the master signing key information on the website + patching the downloaded image). I know what you mean, but it's worth remembering that the Qubes Master Signing Key fingerprint is supposed to be verified out-of-band/multiband. So, in principle, replacing the key and/or fingerprint only just qubes-os.org shouldn't work as a successful attack vector. the problem is (as you wrote) 'supposed to be verified out-of-band'. for some less technical people, even verifying the signature is a huge step. i am a fan of providing easy accessible security and using already existing infrastructure. (in case of the dom0 repo, an ultimately trusted source). also depending on the situation a mitm could replace the fingerprint of different channels, too. also checking signatures manually should unnecessary since a package manager is build to do such stuff. i would propose to add the qubes-images as packages to the repos. Interesting idea. I wonder whether this would count as a misuse of the repos/package manager. One thing is that we'd like to offload most of the traffic to a mirror (e.g., mirrors.kernel.org, as we currently do). if offloading is not done for isos: ad a "qubes-images" repo providing the files and host it on your servers. if offloading is done for isos: ship the master key with qubes and provide a convenience command to the user. this command should download (e.g. via torrent) and verify the image (a step the user can'd do wrong anymore). this command could spawn a dispvm, install torrent software, load the torrent and copy it to dom0. from there the user could qvm-copy it to the vm with the install medium. maybe you could get other official repos to add them, too. (debian (+ubuntu), fedora and arch should reach a significant portion of the linux users) Another interesting idea. I've never heard of a distro adding a different OS's ISO as a package of their own, though. asking can't hurt. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b9970659-6d3d-5fa8-4659-ee94648cb38e%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] RFC: adding qubes images to the (qubes) repo
currently when i have qubes and need a new image (e.g. to reinstall/install on a new machine), i need to download the image from qubes-os.org and then check the signature. this may be a source of errors for some users, or even insecure (mitm + exchanging the master signing key information on the website + patching the downloaded image). also checking signatures manually should unnecessary since a package manager is build to do such stuff. i would propose to add the qubes-images as packages to the repos. maybe you could get other official repos to add them, too. (debian (+ubuntu), fedora and arch should reach a significant portion of the linux users) also: is the public qubes master signing key somewher in dom0? in case a user has not saved it, this could circumvent the problem of an mitm exchanging the information about the signing key -john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a04c000f-b0c1-55e4-535f-50cc2e44b2ed%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Unable to change timezone?
I have already tried that, and it fails with "Failed to set time zone: Unit systemd-timedated.service is masked". I just tried it and it works for me (it even updates the time instantly). did you change stuff in dom0? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/73a8750d-eca6-ee11-6733-4439d29c756d%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] config-vm and inter vm file transfer
hi. currently i am configuring salt to create and configure all my vms. my target is to have only a minimal set of vms i need to backup (vault, config, data, custom systemd based services for my vms) and a set of salt files to create my whole setup. creating vms and installing software works. but for some vms i need additional config data (ssh-keys, openvpn-config file, etc). I want to store this data in the config vm. now i need to get the config data for each vm from my config-vm. i have multiple ideas, but i am not satisfied with any: 1) run `qvm-copy-to-vm` in config-vm + run some copy commands in the target-vm 2) get the file to dom0 via `qvm-run --pass-io "cat " > file_in_dom_0` + transfer the file to the targetvm 3) use managed file from salt why i don't like the solutions: 1) needs user interaction to allow the transaction or i need to allow all file transfers from my config-vm. i like neither of these options. additionally i need to to issue two commands. 2) i don't like the part about transferring anything to dom0. also it would be difficult to handle directories. 3) i would transfer the files to dom0 (i don't want to do this) I am currently searching for a nice way to solve all of this. I have an idea but it would require some new functionality (at leas i think so). in my config-vm i have multiple config folders for each target property (e.g. autoshutdown, QubesOutgoing for my own services). each folder contains files to copy to /rw) in dom0 i would run something like this `qvm-inter-vm-copy config-vm:~/autoshutdown/* some-template:/rw/` this command would copy all files/directories from ~/autoshutdown/ in config-vm to /rw in some-template. the command qvm-inter-vm-copy would only be available in dom0, so it would not need additional user interaction. what do you think about adding such a `qvm-inter-vm-copy`-command to dom0? (the functionality (intervm copy) should mostly already be there). Or is there some other/better way? -john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/24804f51-5109-95c4-a09a-2f3d8904b661%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] using salt to install software in template-vms
On 18/12/16 23:04, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Dec 18, 2016 at 10:47:36PM +, john.david.r.smith wrote: hi. currently i am trying to configure salt to create and setup all my templates and vms. i managed to create the vms and do the config in dom0. then i tried to install software in my template-vms, but this failed. my top: base: tmp-salt: #this is a template (a clone of fedora-23) - q app-salt: #this is an appvm (based on fedora-23) - q my q.sls: /home/user/q: file.touch pkgs: pkg.installed: - pkgs: - htop both vms (tmp-salt, app-salt) contain the file q. no vm has the software installed (this is expected for the appvm). You mean template too? Check salt output (/var/log/qubes/mgmt-tmp-salt.log) for details - maybe this package is unavailable, or there was some network problem. ok, it was a problem with one of the packages from the list (i omitted all but one in this mail) it was the package vim. if i omit it, all other packages get installed. strangely i can install vim via `dnf install vim` or `yum install vim`. what could be the reason for this? both vms have an empty folder from their configuring salt management vm. as updatevm i tried a tor-gw, an updatevm (based on fedora-23) behind a torvm and sys-firewall. what am i doing wrong? You mean /srv there? This is expected. Configuration is copied temporarily there, into /tmp. This is how salt-ssh works. And thanks to salt-ssh, you don't have to install salt in every template to use it to manage VMs. Just default template is enough. i mean the folder /home/user/QubesIncoming/disp-mgmt-tmp-salt (it still is created with my now working sls) -john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ea9d7bc6-877a-1728-09e7-0a7cfb363999%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] using salt to install software in template-vms
hi. currently i am trying to configure salt to create and setup all my templates and vms. i managed to create the vms and do the config in dom0. then i tried to install software in my template-vms, but this failed. my top: base: tmp-salt: #this is a template (a clone of fedora-23) - q app-salt: #this is an appvm (based on fedora-23) - q my q.sls: /home/user/q: file.touch pkgs: pkg.installed: - pkgs: - htop both vms (tmp-salt, app-salt) contain the file q. no vm has the software installed (this is expected for the appvm). both vms have an empty folder from their configuring salt management vm. as updatevm i tried a tor-gw, an updatevm (based on fedora-23) behind a torvm and sys-firewall. what am i doing wrong? -john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2e751f4e-17d7-a46a-234d-c3b35df6386b%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] can't start hvm with a cdrom
On 25/07/16 22:17, Marek Marczykowski-Górecki wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Jul 25, 2016 at 10:06:56PM +0200, john.david.r.smith wrote:
On 25/07/16 21:56, Marek Marczykowski-Górecki wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Jul 25, 2016 at 09:11:03PM +0200, john.david.r.smith wrote:
hi.
i want to install windows 8 in an hvm (so i can update it).
but somehow i can't start the vm with an iso. (see output below)
[user@dom0 ~]$ qvm-start w8 --cdrom=data:/home/user/w8.iso
--> Loading the VM (type = HVM)...
Traceback (most recent call last):
File "/usr/bin/qvm-start", line 131, in
main()
File "/usr/bin/qvm-start", line 115, in main
xid = vm.start(verbose=options.verbose,
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
notify_function=tray_notify_generic if options.tray else None)
File "/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py",
line 326, in start
return super(QubesHVm, self).start(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py",
line 1901, in start
self.libvirt_domain.createWithFlags(libvirt.VIR_DOMAIN_START_PAUSED)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1059, in
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed',
dom=self)
libvirt.libvirtError: internal error: libxenlight failed to create new
domain 'w8'
what am i doing wrong?
i tried different isos, but the error is the same.
i get the same error, if i try to attach a nonexistent file. (but starting
the vm without an iso works (the vm starts and then shuts down, since there
is no bootable medium))
any idea how i can fix this?
Are you sure the path is correct? If so, check
/var/log/libvirt/libxl/libxl-driver.log for more details.
i am pretty sure the path is correct:
[user@data ~]$ ls -l /home/user/w8.iso
-rwxrwxrwx 1 user user 3758010368 Sep 16 2013 /home/user/w8.iso
in libxl-driver.log are more details, but nothing i understand
2016-07-25 22:01:39 CEST libxl: error: libxl_dm.c:1671:stubdom_xswait_cb:
Stubdom 21 for 20 startup: startup timed out
2016-07-25 22:01:39 CEST libxl: error:
libxl_create.c:1339:domcreate_devmodel_started: device model did not start:
-9
Stubdomain startup timeout. Probably something wrong with that 'data'
domain which serves as a backend for your iso image.
Is the 'data' domain based on minimal template? If so, install perl
there. Also check if you have xen-blkback kernel module loaded.
If none of this helps, check /var/log/xen/xen-hotplug.log in data VM and
/var/log/xen/console/guest-w8-dm.log in dom0.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJXlnPoAAoJENuP0xzK19cs8loH/ApbUQXfNmB/7bpN5fPWB9Tl
wMBShn8piejQakQE11gFF8xGrF+C1LtFN6jELYyMRE6XBh65WVks3R/8MAI/N8PH
3LuM2maaaANu8Vx+zVXKBKnU8aR6vzfyKU/QXR/kSnwvTN9vSS27+Jdkb8fmhxJ1
yUIbPzji9AjuQ7HAxLWtsqEApfL9mnSGM7pkqDBZpO/29LlauqilmREw3YvDutMz
xWQvk9D6t+Jy5H4oR7owFVAd+/5bRR3iZurgZZY5NA3thqsDN8rx2/Yt4xJDHb+k
Xdg4LSTUxCeae7vJJqDdqX/CskEBL2zFHA8WIc0YlWRFFiNwSOzgHQSEwI/kQGg=
=bWUQ
-END PGP SIGNATURE-
yes it was a minimal template.
i installed perl and now it works. (the kernel module is loaded, too)
thanks a lot.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/ce1cb40e-91db-a353-76d2-4f94bb8670fb%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] can't start hvm with a cdrom
On 25/07/16 21:56, Marek Marczykowski-Górecki wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Jul 25, 2016 at 09:11:03PM +0200, john.david.r.smith wrote:
hi.
i want to install windows 8 in an hvm (so i can update it).
but somehow i can't start the vm with an iso. (see output below)
[user@dom0 ~]$ qvm-start w8 --cdrom=data:/home/user/w8.iso
--> Loading the VM (type = HVM)...
Traceback (most recent call last):
File "/usr/bin/qvm-start", line 131, in
main()
File "/usr/bin/qvm-start", line 115, in main
xid = vm.start(verbose=options.verbose,
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
notify_function=tray_notify_generic if options.tray else None)
File "/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py",
line 326, in start
return super(QubesHVm, self).start(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py",
line 1901, in start
self.libvirt_domain.createWithFlags(libvirt.VIR_DOMAIN_START_PAUSED)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1059, in
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed',
dom=self)
libvirt.libvirtError: internal error: libxenlight failed to create new
domain 'w8'
what am i doing wrong?
i tried different isos, but the error is the same.
i get the same error, if i try to attach a nonexistent file. (but starting
the vm without an iso works (the vm starts and then shuts down, since there
is no bootable medium))
any idea how i can fix this?
Are you sure the path is correct? If so, check
/var/log/libvirt/libxl/libxl-driver.log for more details.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJXlm7wAAoJENuP0xzK19cscLkH/RyMDckqkNrP4P2WjN9gt7Hb
bS7pR+dFQdri9lTAG0iDJsUaq7uKhtWm7I6N50xHOBLCTkNAUSC0dSWQT+pUCsyx
x1feNrRONyDuQajtnpp5in4UUSsadkxGH/kRCFbZ5Y+XojvImfWZh68ar5doC3N3
ZjQr6y8XU94FTYplUQvVKQxFMzv2LbBPHv3R+Y0GynFck3jUQCXGH0/mfcCtirIF
qmUk26hP59bOmGCnjw4ZRp68kXSSjBYIrkvroanBGryTyZgbJtzIja6AtFI6mrtC
w4HP/RBb/tOzokGrbTY9L8816ZAm2g3r8I7aAHH7R5Gjw9BQWNlMjr0vtMyrLKM=
=8+vV
-END PGP SIGNATURE-
i am pretty sure the path is correct:
[user@data ~]$ ls -l /home/user/w8.iso
-rwxrwxrwx 1 user user 3758010368 Sep 16 2013 /home/user/w8.iso
in libxl-driver.log are more details, but nothing i understand
2016-07-25 22:01:39 CEST libxl: error:
libxl_dm.c:1671:stubdom_xswait_cb: Stubdom 21 for 20 startup: startup
timed out
2016-07-25 22:01:39 CEST libxl: error:
libxl_create.c:1339:domcreate_devmodel_started: device model did not
start: -9
2016-07-25 22:01:39 CEST libxl: error:
libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block
remove [10827] exited with error status 1
2016-07-25 22:01:39 CEST libxl: error:
libxl_device.c:1084:device_hotplug_child_death_cb: script:
/etc/xen/scripts/block failed; error detected.
2016-07-25 22:01:39 CEST libxl: error:
libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block
remove [10819] exited with error status 1
2016-07-25 22:01:39 CEST libxl: error:
libxl_device.c:1084:device_hotplug_child_death_cb: script:
/etc/xen/scripts/block failed; error detected.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/bed72892-8cc5-586d-b820-3cd97cb231f4%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] can't start hvm with a cdrom
hi.
i want to install windows 8 in an hvm (so i can update it).
but somehow i can't start the vm with an iso. (see output below)
[user@dom0 ~]$ qvm-start w8 --cdrom=data:/home/user/w8.iso
--> Loading the VM (type = HVM)...
Traceback (most recent call last):
File "/usr/bin/qvm-start", line 131, in
main()
File "/usr/bin/qvm-start", line 115, in main
xid = vm.start(verbose=options.verbose,
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
notify_function=tray_notify_generic if options.tray else None)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line
326, in start
return super(QubesHVm, self).start(*args, **kwargs)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line
1901, in start
self.libvirt_domain.createWithFlags(libvirt.VIR_DOMAIN_START_PAUSED)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1059, in
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
failed', dom=self)
libvirt.libvirtError: internal error: libxenlight failed to create new
domain 'w8'
what am i doing wrong?
i tried different isos, but the error is the same.
i get the same error, if i try to attach a nonexistent file. (but
starting the vm without an iso works (the vm starts and then shuts down,
since there is no bootable medium))
any idea how i can fix this?
-john
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/4de76cda-197e-368e-521b-dcd73d4dd633%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] steam in linux appvm
hi. i want to play some linux games through steam in a appvm (based on debian). when starting steam i get this error: "OpenGL GLX extension not supported by display" i guess this is the case, since i did not pass any GPU to the vm. So i tried passing my nvidia gt 740m. If i set up its device to pass to the vm and start the vm, my desktop freezes. So i tried passing the gpu of my i7. If i set up its device to pass to the vm and start the vm, my system reboots. Was anyone able to pass a gpu to a linux vm? has anyone an idea how i could solve the problem? (if passing does not work, maybe some virtual gpu is enough, since the game should not require much graphics power) is there maybe some additional device i have to pass (e.g. similar to the cpu controller for a usb-vm). -john Ps: i passed following devices nvidia: "3d controller: NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)" i7: "VGA compatible controller: IntelCorporation 4th Gen Core Processor Integrated Graphics Contoller (rev 06)" -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ad70c30f-f000-bb32-02e9-5c756561b169%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Does Qubes play well with Computer vision, and ML?
i never tried, but you can pass your pci devices to an appvm (e.g. your gpu). https://www.qubes-os.org/doc/assigning-devices/ frameworks will often allow you to use your cpu in case you have no gpu. as long as your models are small enough you can train that on cpu. (but training a big nn (neuronal network, but i guess you know that) will take a long time and cnns (and other deep nns) are big). so passing through your gpu would be the best course of action. (maybe your university provides some pcs with standard dev software and ssh-access. you could try using those.) -john -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4f7ed783-52ba-5305-23ed-8ff33f9e8eb7%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
