Hello,
I am wondering if there is a straightforward way to spoof the CPUID to an
AppVM, more specifically, to remove the "XenVMMXenVMM" string?
I am aware of these patches:
https://gist.github.com/dylangerdaly/2ec8172116e63fd56feb0cf95f4d5a69
https://gist.github.com/dylangerdaly/74be3f316ce8f0d
Another option, depending on the machine, is add another ethernet nic or wifi
dongle. Create a vm that 'provides network' and enable network manager in that
vm (im calling it sys-lan here). Then assign the new nic or dongle to sys-lan.
Assign netVMs like usual sys-net>sys-firewall>sys-whonix>sys
I did find one thing that may or may not be related. The NICs on my machine
are Realtek 8111E and there is some chatter on the Internets that the
standard driver for this NIC family are buggy. During install debian and
fedora default to the driver 'r8169' which is suspect. The correct driver
sh
What about a rolling release model for all qubes like arch linux?
This way there is one static state for all VMs, in their default state.
No need to retool for version upgrades on at least two different
distributions, three if you count dom0.
One standard template can be maintained like a servic
I know this is not what you are asking for, but I was able to get a
deb-10-minimal vpn vm by following the vpn write up in the qubes docs. The
only problem is the little pop up window for VPN UP or DOWN does not work
properly but I did not bother finding out why.
On Friday, January 24, 2020 a
I had three cameras attached to a PoE switch, which was plugged into a NIC
on a qubes machine. They ran through an OpnSense hvm(standalone) and out
through sys-net. Performance was fine but I wanted to move to a qubes
template-based vm to control the NIC.
So I created a Debian-10-minimal templ
I noticed some services were a bit laggy lately and pinged from an APPVM to
sys-net. There appeared to be a .500ms delay per hop to sys net. So APPVM >
sys-firewall > sys-net = about 1ms delay. This becomes fairly substantial
if there are other ProxyVMs like a sys-vpn or whonix. This occurs usin
> January 5, 2020 7:50 PM, "Franz" <169...@gmail.com> wrote:
>
> > May be it already somehow exists and I am not aware of it, but it would be
> > very
> > interesting to be able to save backup settings, that is a list of VMs that
> > contain
> > your current ordinary activity and you want to bac
> I've setup a machine running R2 since i need audio working on Windows HVM.
>
> I would like to install QWT but when i run sudo-qubes-dom0-update i get the
> following error:
>
> One of the configured repositories failed (Fedora 20 - x86_64)
> ...
> Cannot retreive metalink for repository:
Good day,
I have dnscrypt-proxy working in sys-net only. But I am stuck on how to
forward dns requests moving from sys firewall and the vms behind it so that
sys-net can route them out via the proxy.
I only have dnscrypt-proxy running, it is not combined with unbound or
dnsmasq.
The firewall ru
oh I am dumb, perhaps try logging in with your template vm, do the key
exchange, and then shut it down. It may stick into the appvm?
On Thursday, August 15, 2019 at 11:15:46 AM UTC-7, 799 wrote:
>
> Hello,
>
> *Null* ** > schrieb am Do., 15. Aug.
> 2019, 19:12:
>
>> O
Oh yeah /home is saved too... I thought just /rw. It is advised on the
nextcloud hardening guide to not keep it in the default location and on my
setup I had to move it anyways because of how the machine is set up.
--
You received this message because you are subscribed to the Google Groups
"q
OCC commands:
https://docs.nextcloud.com/server/16/admin_manual/configuration_server/occ_command.html#user-commands-label
In qubes you have to specify the file path to occ(in the docs it lets you call
occ by itself).
So for a typical fedora/apache/nc install in the template you would enter:
Sud
I upgraded a fedora minimal based template using the qubes docs guide but one
program i was using gor downgraded in the process. Manually upgrading it is a
huge pain.
Is there an option to exclude a certian app from the process?
--
You received this message because you are subscribed to the G
Sorry my initial reply was the wrong answer.
To set up a login that is persistant you need to do it in the template with the
occ commands. Any user made in the appvm will not survive a reboot.
The nextcloud storage area needs to be made persistant using the
qubes-bind-dirs directory in the appv
Youve got to set up your user names in the template. So fire up httpd in your
template and use the occ commands to add users. Its inconvienent, but the appvm
non persistance is the secuity feature that is also preventing anyone from
embedding anything too nasty in your system.
I have tried to f
Would installing haproxy on sys-net compromise the standard qubes firewall
scheme?
I know there is an elevated risk in accepting incoming requests. But currently
I have port forwarding enabled to expose certian services to the outside world,
and my understanding of port forwarding is that it is
On Sunday, July 14, 2019 at 7:21:08 AM UTC-7, unman wrote:
> On Sat, Jul 13, 2019 at 02:09:14PM -0700, *Null* ** wrote:
> > I have a FreeBSD HVM connected to a firewall VM. I also have a Fedora Qube
> > connected to the same firewall VM. Networking between these was enabled
I have a FreeBSD HVM connected to a firewall VM. I also have a Fedora Qube
connected to the same firewall VM. Networking between these was enabled using
the iptables instructions from the Qubes documentation.
I can ping and access resources on the Fedora Qube from FreeBSD(I can transfer
files t
19 matches
Mail list logo