-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Jul 02, 2016 at 02:30:15PM +0200, Alex wrote: > On 07/02/2016 02:19 PM, Achim Patzner wrote: > > Hi! > > > > > > Am I the only one who would like an integrated name service management > > for local services that will be provisioned at the time of VM creation > > (e. g. if you create a machine "builder" its assigned IP address could > > be added to the locally running dnsmasq on the NetVM)? > This somehow is against the principle of "isolation" between the > AppVM... But I can understand that, from a developer point of view, this > may be helpful - if, for example, you develop web-apps and assign a > web-app per AppVM to host. > > Yet, Qubes OS is designed for workstations, and it may be argued that > developer workstations may host the services they are developing. I > think, IMHO, that this is wrong, and may lead to unnecessary complexity > in dealing with the subtleties of the application working on the > developer's workstation but not in production. I would recommend to test > them on the work AppVM, and then complete testing in a staging environment.
I use somehow similar workflow - have code in one VM, then compile and test in other VM. To transfer between those VMs I use git connection. Take a look here for details: https://www.qubes-os.org/doc/development-workflow/#tocAnchor-1-1-3 Also another possibility is to send already compiled artifacts to testing VM, then trigger a script which will deploy whatever landed in `~/QubesIncoming/development-vm`. Some variant of it is described here: https://www.qubes-os.org/doc/development-workflow/#tocAnchor-1-1-4 > I myself built a low-cost staging machine, with proxmox and several VMs > with a centos template: my production machines are typical VPSs with > centos, so the differences between staging and production are minimal. > > Beyond the developer point of view, do you think there would be other > examples that would benefit from having Qubes AppVMs mutually visible? > (thus needing an auto-registering name resolution system?) Generally, if your workflow assume frequent communication between two VMs, it may mean you do something wrong - those VMs should either not communicate at all, or be a single VM. But there may be also valid use cases - for example for uni-directional communication (you send something to less trusted VM and never retrieve it back). Also it's better to use qrexec services for that, to reduce attack surface (all the networking stack, plus enforce policy using dom0, instead of potentially compromised netvm or firewallvm). It should be easy to hook any TCP connection into qrexec using socat. Something like this (untested): source VM: launch this somewhere (/rw/config/rc.local?) socat TCP-LISTEN:4444,fork EXEC:"qrexec-client-vm target-vm my-tcp-service" target VM: /usr/local/etc/qubes-rpc/my-tcp-service (this is stored in /rw): socat STDIO TCP:localhost:4444 dom0: /etc/qubes-rpc/policy/my-tcp-service source-vm target-vm allow @Andrew do you think we should have this documented somewhere? Or maybe even some tooling to ease such setups? But first it would good to actually test above instruction ;) - -- 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 iQEcBAEBCAAGBQJXeVlvAAoJENuP0xzK19cssnYH/0ZwyhJlnM/8stSimn8Yoadt 1tBdpbEmA2ksHgbKNdpMhuOJthcmwL/sdPSqoPPyqzDfaWICsSWpi3zWyKSLNhzm Emd8ub398xSm9TLOqpcOWhc4hLSfSE2QwUAhWvqq6V8zthsv9UePRYNL8Vd5QSpy zQe/8pRhQUMF1TRPrQEIdXnNI5Q2wVQEBSHV91Gu6LtCYLQAkzSGRRggroM0NUxt 4IKygVsm9b29UVwMQ8Uj4Jqby7hEi/4fV+zQgQ1Wue//8enQl3CR8S2lNu/54yhh XcHLv4KUpCHoD5YQfDEiN4xssKbmUV4rgKbN2wVcUvQmmUhNDkd/UvyFcp/crfU= =geL0 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20160703182905.GY1323%40mail-itl. For more options, visit https://groups.google.com/d/optout.
