Debian Network VMs

[cprise]

On some VMs I've started replacing fedora with debian 7. So far its
working for my firewall and VPN, but the netvm refuses to work. After
manually adding the iwlwifi firmware the system creates a wlan device on
boot, but networkmanager is unable to make a connection.

Is the debian template not yet ready for netvm duty, or am I doing
something wrong?

[nrgaway]

On 11 April 2015 at 13:12, cprise <cpr...@gmail.com> wrote:

On some VMs I've started replacing fedora with debian 7. So far its working for my firewall and VPN, but the netvm refuses to work. After manually adding the iwlwifi firmware the system creates a wlan device on boot, but networkmanager is unable to make a connection.

Is the debian template not yet ready for netvm duty, or am I doing something wrong?

Have you assigned the proper pci devices  to the netvm?

[cprise]

On 04/11/15 14:05, nrgaway wrote:
>
> On 11 April 2015 at 13:12, cprise <cpr...@gmail.com

Yes, one ethernet and one wifi. And there are no conflicting assignments
in other VMs.

The ethernet link basically works (at least I can ping from the netvm).
NM does show 2 wired connections, however, with 'Wired Connection 2'
being a vif. And NM keeps trying to connect to ...I dunno....
something?... even when eth0 is connected and wifi is disabled; the
swirly animation keeps re-displaying.

Also, with eth0 connected there is no forwarding of traffic, so my
proxyvms and appvms can't access the Internet. I haven't yet checked to
see if forwarding needs manual setup.

Wifi won't connect at all. NM shows a list of access points but that's
it. If I click on an AP while eth0 is connected, absolutely nothing
happens. If I click while eth0 is disconnected, a notification
immediately appears saying 'Disconnected. The network connection has
been disconnected.' There is no prompt for an AP passphrase. I already
checked that wpasupplicant is installed.

Here is the relevant section from /var/log/messages:

Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Activation
(wlan0) starting connection 'XYZ'
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> (wlan0): device
state change: disconnected -> prepare (reason 'none') [30 40 0]
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Activation
(wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Activation
(wlan0) Stage 1 of 5 (Device Prepare) started...
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Activation
(wlan0) Stage 2 of 5 (Device Configure) scheduled...
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Activation
(wlan0) Stage 1 of 5 (Device Prepare) complete.
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Activation
(wlan0) Stage 2 of 5 (Device Configure) starting...
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> (wlan0): device
state change: prepare -> config (reason 'none') [40 50 0]
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Activation
(wlan0/wireless): access point 'XYZ' has security, but secrets are required.
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> (wlan0): device
state change: config -> need-auth (reason 'none') [50 60 0]
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Activation
(wlan0) Stage 2 of 5 (Device Configure) complete.
Apr 11 16:53:42 localhost NetworkManager[1760]: <warn> No agents were
available for this request.
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> (wlan0): device
state change: need-auth -> failed (reason 'no-secrets') [60 120 7]
Apr 11 16:53:42 localhost NetworkManager[1760]: <warn> Activation
(wlan0) failed for access point (XYZ)
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Marking
connection 'XYZ' invalid.
Apr 11 16:53:42 localhost NetworkManager[1760]: <warn> Activation
(wlan0) failed.
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> (wlan0): device
state change: failed -> disconnected (reason 'none') [120 30 0]
Apr 11 16:53:42 localhost NetworkManager[1760]: <info> (wlan0):
deactivating device (reason 'none') [0]

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 11, 2015 at 05:11:08PM -0400, cprise wrote:
> On 04/11/15 14:05, nrgaway wrote:
> >
> >On 11 April 2015 at 13:12, cprise <cpr...@gmail.com
> ><mailto:cpr...@gmail.com>> wrote:
> >
> > On some VMs I've started replacing fedora with debian 7. So far its
> > working for my firewall and VPN, but the netvm refuses to work.
> > After manually adding the iwlwifi firmware the system creates a wlan
> > device on boot, but networkmanager is unable to make a connection.
> >
> > Is the debian template not yet ready for netvm duty, or am I doing
> > something wrong?
> >
> >
> >Have you assigned the proper pci devices to the netvm?
>
> Yes, one ethernet and one wifi. And there are no conflicting assignments in
> other VMs.
>
> The ethernet link basically works (at least I can ping from the netvm). NM
> does show 2 wired connections, however, with 'Wired Connection 2' being a
> vif. And NM keeps trying to connect to ...I dunno.... something?... even
> when eth0 is connected and wifi is disabled; the swirly animation keeps
> re-displaying.

This can be a problem - I guess it tries to get IP on vif* interface
using DHCP, which will of course fail. And will break connection to
downstream VMs... NetworkManager should ignore those interfaces (should
be marked as "unmanaged"). Check if that's true in
/etc/NetworkManager/NetworkManager.conf, you should have something like
this:
[main]
plugins=keyfile
[keyfile]
unmanaged-devices=mac:fe:ff:ff:ff:ff:ff

> Also, with eth0 connected there is no forwarding of traffic, so my proxyvms
> and appvms can't access the Internet. I haven't yet checked to see if
> forwarding needs manual setup.

This can be related to the above problem.

This looks like nm-applet do not want to as you for a passphrase. Maybe
you can try to enter them manually in connection editor? I'm not sure
what nm-applet requires to prompt for the password. Maybe gnome-keyring?

> Apr 11 16:53:42 localhost NetworkManager[1760]: <warn> Activation (wlan0)
> failed for access point (XYZ)
> Apr 11 16:53:42 localhost NetworkManager[1760]: <info> Marking connection
> 'XYZ' invalid.
> Apr 11 16:53:42 localhost NetworkManager[1760]: <warn> Activation (wlan0)
> failed.
> Apr 11 16:53:42 localhost NetworkManager[1760]: <info> (wlan0): device state
> change: failed -> disconnected (reason 'none') [120 30 0]
> Apr 11 16:53:42 localhost NetworkManager[1760]: <info> (wlan0): deactivating
> device (reason 'none') [0]

@nrgaway:
One additional, NetworkManager related problem I've found during
testing: On Debian 7, when you enable NetworkManager in
ProxyVM/AppVM (qvm-service VMNAME -e network-manager), startup scripts
prepare static configuration for eth0 based on Qubes settings (via
xenstore/qubesdb). It is created by setup-ip script and the output file
is /etc/NetworkManager/system-connections/qubes-uplink-eth0. Apparently
NetworkManager in Debian 7 does not understand this file:

- -----
Apr 12 00:14:54 localhost NetworkManager[1495]: keyfile: parsing
qubes-uplink-eth0 ...
Apr 12 00:14:54 localhost NetworkManager[1495]: Unknown setting
'ethernet'
Apr 12 00:14:54 localhost NetworkManager[1495]: Invalid setting name
'ethernet'
Apr 12 00:14:54 localhost NetworkManager[1495]: read_ip4_addresses:
ignoring invalid IPv4 address item ''
Apr 12 00:14:54 localhost NetworkManager[1495]: keyfile: error:
invalid or missing connection property 'addresses'
- -----

And tries to configure eth0 using DHCP...
The same file works on Debian 8. It looks like this:
- -----
[802-3-ethernet]
duplex=full

[ethernet]
mac-address=00:16:3e:5e:6c:30

[connection]
id=VM uplink eth0
uuid=de85f79b-8c3d-405f-a652-cb4c10b4f9ef
type=802-3-ethernet

[ipv6]
method=ignore

[ipv4]
method=manual
may-fail=false
dns=10.137.1.1;10.137.1.254
address1=10.137.1.50/32,10.137.1.1
- -----

I've created a ticket for this problem here:
https://github.com/QubesOS/qubes-issues/issues/955


- --
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 v1

iQEcBAEBAgAGBQJVKZ82AAoJENuP0xzK19csMn8H/3NXEiG0tkcfn4SKQlX+xVDZ
vqnr3rEchtbx8uy1/71io5Ru/Ti19zngCwN9jJ9ChlM/5E/ij2Io5gLChjrtzYaS
qkFUZDM9m1WCYv9WsyOgu5opD8oysKNEt/0KcPkUGxBIVvVEEtnmzX6sjjFr7JU0
C4pGVkF6FIsCjeSFdSyJDfozXKMf/h5WgV3SME9LXPEoR0UMKYoBjQHAOyiRUdeU
n7Y7leC6Bq29qHgZM+GcA8YcrP3hQuCAbHPBzQNYrJygKFirdwjLZ8jb9/HYEKjj
CFH/cSCibQDCzIr2H1e235vRpu/pPfA0ZfJ2suNw/wKYrOnRlxHnG1wA5UXJhek=
=P5VZ
-----END PGP SIGNATURE-----

[cprise]

Thanks, Marek. Both the NetworkManager.conf and connection editing
workarounds have gotten the debian 7 netvm connected and forwarding traffic.

[cprise]

One problem that has cropped up with the new netvm is that is doesn't
recover from sleep. NM status remains 'Connected' but there is no
activity and no signs of trying to re-establish the connection.

I have to disable networking then re-enable it to get wifi working again.

[cprise]

Is there a way to have a debian-based proxyvm handle dom0 updates?

[nrgaway]

On 12 April 2015 at 21:48, cprise <cpr...@gmail.com> wrote:

Is there a way to have a debian-based proxyvm handle dom0 updates?

I wonder if it would work if you install yum (apt-get install yum).  Not sure if you need to set up any default repos or keys though.  Might be an interesting experiment...

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just installing yum should be enough. qubes-dom0-update will copy all
the required configuration there.

- --
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 v1

iQEcBAEBAgAGBQJVK3KzAAoJENuP0xzK19csIhwH/0B+IewJWuJQyaXN2RuwQLYn
A7RT5dYlUOkbfMA2ILzdFnKV2TqTGyZQbdqtlIrxjBhwF0BUMe0kZYZLL3NO/Qi4
zDLJnifJ/cETJFQ+MTZqyqNRrVh0/visPxbNEkEM5g7hS/LEZ/x8jjHX7GHVrzcj
tCeD1Zpclz9KN0dvgQsjmWGWl149DH7BLOw34qqtxwk4/i8CrOt/zcAk+2z6Sn7Z
QAPtlhBRFU3xCXpJI3QAgqz78+2isMxeWKtPFOFOqwWu6IDYaauEwrawh9DefcqU
/e3OYfDHe3B3osc6V+YWGsfa9EAYTzOdATw6EI9IDVMDbPf1RCELCfjSbPjokjA=
=F67H
-----END PGP SIGNATURE-----

[cprise]

On 04/13/15 03:39, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, Apr 13, 2015 at 12:44:51AM -0400, nrgaway wrote:
>> On 12 April 2015 at 21:48, cprise <cpr...@gmail.com> wrote:
>>
>>> Is there a way to have a debian-based proxyvm handle dom0 updates?
>>>
>>>
>> I wonder if it would work if you install yum (apt-get install yum). Not
>> sure if you need to set up any default repos or keys though. Might be an
>> interesting experiment...
>
> Just installing yum should be enough. qubes-dom0-update will copy all
> the required configuration there.
>
> - --

I installed yum in the debian 8 template, which is currently used by
firewallvm. Here is the result from update...


$ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
ClockVM not started, exiting!
Using firewallvm as UpdateVM to download updates for Dom0; this may take
some time...
Running command on VM: 'firewallvm'...
Starting the VM 'firewallvm'...
--> Cleaning volatile image:
/var/lib/qubes/servicevms/firewallvm/volatile.img...
--> Loading the VM (type = ProxyVM)...
--> Setting Xen Store info for the VM...
--> Updating firewall rules...
--> Starting the VM...
--> Starting the qrexec daemon...
Waiting for VM's qrexec agent.......connected
tar: /var/lib/qubes/dom0-updates: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
write daemon: Connection reset by peer
-su: /usr/lib/qubes/qubes-download-dom0-updates.sh: No such file or
directory

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Indeed this script isn't packaged in debian, I wonder why... Will be
available in next update (hopefully this week).

- --
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 v1

iQEcBAEBAgAGBQJVK6RoAAoJENuP0xzK19csieAH/A+9QbuY29zoPHTgEIX0aXOe
FjFXlBEWdxp+c3NjQN8UCf8rEDe69r0MEP97V5wUAsq5LL4teOQAGI+LMK1x2dgQ
AllYHDtZIQxW4SHvWB2lm7cXGYZ+of46Rtoqr4XtFQDZ9KKXMHH9akGnILQiUAbv
feSwpD4R7vgopCM1MNJTXhV5X7w8yCGjC+AJsotTtlQOTeyJ8orzERBgDeE789EC
jRGIwkyO9r+AGb5F6SJH2bUlAWX0uLltBlTClNxNe9seCCob2M2QKUh93rMsW3ip
RlGOXUC92vOCwLQuZN6A6emJQEozySQOsDu3X9T0sVBzk/76DgCUPnh+N9PRLac=
=IsO8
-----END PGP SIGNATURE-----

[cprise]

Since I fixed the debian 8 locales I'm able to use it for the netvm, and
NM no longer has this problem.

[cprise]

I'm still getting flakiness from debian 8 vms. Currently the
Files/nautilus program doesn't (usually) run when I try to launch it
from dom0.

Here is the log entry an attempted launch produces:

Apr 13 14:59:02 localhost org.gnome.Nautilus[1329]: (nautilus:1854):
Gtk-WARNING **: Failed to register client:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.SessionManager was not provided by any .service files



This may be another clue... If I paste the qvm-run command from the
launcher into CLI it still doesn't work initially. But if I run it
repeatedly in quick succession then it starts to work after a couple
tries. Then if I wait for a minute the next try won't run nautilus and
another error will be added to the log.

More odd behavior... When I run nautilus directly from gnome-terminal in
the vm and then exit, the program waits for about 10 seconds before
returning control to the CLI.

[cprise]

The exit delay is closely linked to the ability to run nautilus from
dom0. As soon as the nautilus process exits back to the terminal, that's
when a subsequent qvm-run won't produce a nautilus window. Furthermore,
the exit will be delayed longer and longer if I keep running nautilus
from dom0.

So, I can run and exit nautilus in vm terminal, and before the exit is
complete I can run nautilus from dom0 which will open another nautilus
window. As long as that last window remains open the process in the vm
terminal won't exit.

Nautilus appears to be starting some kind of gnome session service
within its own process and keeping that alive as long as there are other
processes running that use the service. This suggests to me that
something is missing from the vm startup.

(BTW, I have another d8 template with mate desktop 'task' installed. It
behaves the same as above.)