dom0 networking

[abb]

Hi,

Qubes wiki says qvm-dom0-network-via-netvm should be used to attach dom0 to the network. I don't find such script in my dom0, instead there is
qubes-dom0-network-via-netvm. It also accepts up/down parameter, so I suppose it it the same but docs are outdated.

When I try using it, it executes without errors, but networking does not work.

===============================================================
[abb@dom0 ~]$ sudo /usr/bin/qubes-dom0-network-via-netvm up

[abb@dom0 ~]$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 eth0

[abb@dom0 ~]$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:16:3E:60:48:4D 
          inet addr:10.137.0.1  Bcast:10.137.0.1  Mask:255.255.255.255
          inet6 addr: fe80::216:3eff:fe60:484d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

[abb@dom0 ~]$ ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.137.0.1 icmp_seq=1 Destination Host Unreachable
...
===============================================================

Apparently, ping running in dom0 actually tries to arp-resolve 8.8.8.8 instead of forwarding packets towards netvm:

===============================================================
[user@netvm user]$ sudo tcpdump -lni vif0.0
...
20:39:26.017328 ARP, Request who-has 8.8.8.8 tell 10.137.0.1, length 28
...

[user@netvm user]$ ifconfig vif0.0
vif0.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.137.0.1  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 fe80::fcff:ffff:feff:ffff  prefixlen 64  scopeid 0x20<link>
        ether fe:ff:ff:ff:ff:ff  txqueuelen 32  (Ethernet)
...
===============================================================

The script is supposed to pause all VMs except dom0 and netvm, which does happen. Also:

[abb@dom0 ~]$ sudo /usr/bin/qubes-dom0-network-via-netvm down
There is a dedicated netvm, but device eth0 is present
and it is not a Xen interface. Refusing to continue.

What is the procedure to activate networking in dom0 these days? Any better way to access git from dom0 on a development machine?

Regards,
Alex

[Joanna Rutkowska]

I usually just do (in dom0):

qvm-run -p appvm 'cat /path/to/file' > file

... which copies the file 'file' from an 'appvm' domain to Dom0 as 'file'.

joanna.

[abb]

I see. Well, it sounds logical to have git working copy in dom0 when developing scripts there.
 

[Marek Marczykowski]

On 07.10.2012 20:50, abb wrote:
> Hi,
>
> Qubes wiki says qvm-dom0-network-via-netvm should be used to attach dom0 to
> the network. I don't find such script in my dom0, instead there is
> qubes-dom0-network-via-netvm. It also accepts up/down parameter, so I
> suppose it it the same but docs are outdated.
>
> When I try using it, it executes without errors, but networking does not
> work.

(...)

Indeed it isn't working now... I will investigate it, thanks for the report.

> What is the procedure to activate networking in dom0 these days? Any better
> way to access git from dom0 on a development machine?

I actually keep git repository in some VM and copy to dom0 ready rpms
(qubes-builder is able to build dom0 fc13 rpms even when VM is based on fc17).

When working on some more complex dom0 script, sometimes I do it in dom0, but
then copy it to devel VM (using method similar to Joanna's one):
tar c devel-dir | qvm-run -p devel 'cd /tmp; tar xv'

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[abb]

Thanks, I've resorted to something like this as well.
 

[Abel Luck]

Marek Marczykowski:

It would be great if we could get a "Tips & Tricks" page under the
Developer section of the wiki containing little snippets like this.

What do you think?

[Joanna Rutkowska]

Abel, if you're interested we could create a trac account for you, so
you could edit our wiki pages (and also create tickets)? let me know if
you are interested?

joanna.

[abb]

On Sunday, October 7, 2012 11:09:50 PM UTC+2, Marek Marczykowski wrote:

On 07.10.2012 20:50, abb wrote:
> Hi,
>
> Qubes wiki says qvm-dom0-network-via-netvm should be used to attach dom0 to
> the network. I don't find such script in my dom0, instead there is
> qubes-dom0-network-via-netvm. It also accepts up/down parameter, so I
> suppose it it the same but docs are outdated.
>
> When I try using it, it executes without errors, but networking does not
> work.

(...)

Indeed it isn't working now... I will investigate it, thanks for the report.

Here is a workaround for issue #660. Attached is a patch to qubes-dom0-network-via-netvm to fix dom0-side. Now qubes-dom0-network-via-netvm up/down work and there is L2 connectivity between dom0 and netvm.

I don't have a patch for netvm, the following needs to be done manually:
 ifconfig vif0.0 10.137.0.2/32
 ip route add 10.137.0.1/32 dev vif0.0

After this is done, dom0 should have network connectivity.

[Joanna Rutkowska]

On 10/18/12 06:08, abb wrote:
> On Sunday, October 7, 2012 11:09:50 PM UTC+2, Marek Marczykowski wrote:
>> >
>> > On 07.10.2012 20:50, abb wrote:
>>> > > Hi,
>>> > >
>>> > > Qubes wiki says qvm-dom0-network-via-netvm should be used to attach dom0
>> > to
>>> > > the network. I don't find such script in my dom0, instead there is
>>> > > qubes-dom0-network-via-netvm. It also accepts up/down parameter, so I
>>> > > suppose it it the same but docs are outdated.
>>> > >
>>> > > When I try using it, it executes without errors, but networking does not
>>> > > work.
>> >
>> > (...)
>> >
>> > Indeed it isn't working now... I will investigate it, thanks for the
>> > report.
>> >
> Here is a workaround for issue #660. Attached is a patch to
> qubes-dom0-network-via-netvm to fix dom0-side. Now
> qubes-dom0-network-via-netvm up/down work and there is L2 connectivity
> between dom0 and netvm.
>
> I don't have a patch for netvm, the following needs to be done manually:
> ifconfig vif0.0 10.137.0.2/32
> ip route add 10.137.0.1/32 dev vif0.0
>
> After this is done, dom0 should have network connectivity.
>
>

Thanks for sharing this, but actually we been thinking whether it makes
sense at all to continue to have this script in Dom0? Can you name some
reasons why you would like to use Dom0 networking at all?

Thanks,
joanna.

[Joanna Rutkowska]

[Adding back list]

On 10/18/12 11:54, Alexandre Bezroutchko wrote:
>> Thanks for sharing this, but actually we been thinking whether it makes
>> > sense at all to continue to have this script in Dom0? Can you name some
>> > reasons why you would like to use Dom0 networking at all?
>> >

> Major reason is to have git in dom0 working in full, meaning push/fetch
> working properly. I understand there are workarounds with copying repos
> back and forth, but I believe it is not the way git is designed to work, it
> is simply inconvenient, error-prone, etc. To me default arrangement of no
> connectivity with manual network activation (there was also something about
> freezing all other VMs which I understand is not implemented yet) are all
> good ideas.

But one should not run any user apps in Dom0, that's a major assumption
in Qubes Architecture. Also, a good development practice tells that one
should not do development and testing on the same machine (VM).

So, I'm still unconvinced, and I would be voting to actually remove this
script, so that people don't have temptation to break Qubes security
model...

joanna.

[Joanna Rutkowska]

BTW, the original reason for this script, IIRC, was to allow Dom0
updates back in the days when we didn't have the secure "networkless"
update mechanism for Dom0, that we have now.

joanna.

[Abel Luck]

Joanna Rutkowska:

I tend to agree here. By default Qubes should do as much as possible to
protect its security model.

On the other hand I support the user's freedom to do what she wants.

One legitimate reason to have networking in dom0 is purely for
development+testing installations, but nothing stops a user from
downloading that script into their own production dom0.

However, that act, downloading some script from somewhere to provide
non-standard functionality is a strong indicator to purposefully break
the security model, which one should allow imho.

To Alexandre's original issue, why do you need git in dom0? Do your
builds +development in a VM and then copy the RPMs back to dom0 to install.

~abel

[Joanna Rutkowska]

You can always download script via some other AppVM and then copy the
rpms/files to Dom0 using the simple method I outlined earlier. User's
freedom doesn't get hurt.

joanna.

[Alexandre Bezroutchko]

There is nothing wrong with your approach if you think it is acceptable (or even beneficial) to have steeper learning curve for people who contribute to the development of Qubes. My point of view is everybody has their own ways of doing things, and often it is more productive to let people use the skills they already have to do the jobs instead of trying to reshape them for greater good. Admittedly I'm not particularly disciplined developer, and the idea of going through edit-rpmbuild-copy-install-test while switching between two VMs in a process does not appeal to me, to put it mildly. I want to have much shorter edit-install-test cycle within one VM. Anyway, this is more of a policy decision I think. If you want to make a point of not permitting shortcuts in the development process at the expense of fewer contributions, why not. If you ask me, I certainly would like to retain proper IP connectivity from dom0 as an option. As Abel says, letting users to break the security model in a controlled fashion is not necessary bad idea.

Cheers,
Alex

joanna.

[Joanna Rutkowska]

A proper discipline in the devel process cannot be underestimated IMHO.
Every shortcut you make in the devel process WILL strike back at you, or
others, sooner or later, especially in case of a more complex product. I
have witnessed it numerous times, especially in case of Qubes. Nobody's
perfect in this respect, and surely Qubes is not a perfect example of
proper, disciplined development process, but surely there is nothing to
be proud about it...

joanna.

[Juergen Schinker]

I disagree there is a lot to be proud of. I esp appreciate the GUI daemon but IMHO there should be a lot more Versions for different OSses.
The Debian world is screaming for a deb-version...The potential for this Distribution is huge ...

BTW i use Qubes-OS on a 2G Laptop , i know but i plan to use it on my Desktop/Server as well....

Cheers
Juergen

[Bruce Downs]

On Thu, Oct 18, 2012 at 7:40 AM, Juergen Schinker
<ba1...@homie.homelinux.net> wrote:
> I disagree there is a lot to be proud of. I esp appreciate the GUI daemon but IMHO there should be a lot more Versions for different OSses.
> The Debian world is screaming for a deb-version...The potential for this Distribution is huge ...

Is anyone seriously working on a debian/ubuntu/mint template vm? It'd
be an interesting exercise.

>
> BTW i use Qubes-OS on a 2G Laptop , i know but i plan to use it on my Desktop/Server as well....
>
> Cheers
> Juergen
>
> ----- Original Message -----
>> A proper discipline in the devel process cannot be underestimated
>> IMHO.
>> Every shortcut you make in the devel process WILL strike back at you,
>> or
>> others, sooner or later, especially in case of a more complex
>> product. I
>> have witnessed it numerous times, especially in case of Qubes.
>> Nobody's
>> perfect in this respect, and surely Qubes is not a perfect example of
>> proper, disciplined development process, but surely there is nothing
>> to
>> be proud about it...
>>
>> joanna.
>>
>

> --
>
>

[abb]

Indeed, I agree with this.
 

[Mark Reynolds]

Yes, I am working on an Ubuntu template VM.

- Mark Reynolds

>
> --
>
>

--

[Danny Fullerton]

I might find some time to work on getting a NetBSD VM. Creating one and making it work doesn't seem to be a big challenge but I'm not quite sure how to integrate this in the build process. 

Any info on this? 

Sent from Mobile

--
 
 

[Juergen Schinker]

woohooo your my hero - what is your bigest Problem right now?

Thanks
J

---

--
 
 

[Alexandre Bezroutchko]

I have tried booting NetBSD 6.0 using Marek's instructions in "non-qubes" thread here. Network drivers didn't work for me, but I didn't do much testing though.

--
 
 

[Bruce Downs]

On Thu, Oct 18, 2012 at 11:40 AM, Mark Reynolds <mark...@bu.edu> wrote:
> Yes, I am working on an Ubuntu template VM.

Would you mind sharing the progress you have made?

> --
>
>

[Marek Marczykowski]

On test machine I use attached scripts to transfer some selected files from
repo in "devel" VM to dom0 omitting rpmbuild. It also make backup of critical
files before overriding.
This can be used to test some work-in-progress version. You can also use
similar script to transfer files changed in dom0 back to "devel" VM. In any
case final commit should be tested by installing rpm (eg to make sure that all
files are included in package...).

[Mark Reynolds]

I have only just begun this effort. I am characterizing FC dependencies

into hard and not-so-hard, so that I can attack the hardest compatibility

issues first. I wish I had more to offer, but it is still early days for

Ubuntu template VM.

- Mark Reynolds

On Thu, Oct 18, 2012 at 6:29 PM, Marek Marczykowski <marm...@invisiblethingslab.com> wrote:

On 18.10.2012 13:30, Alexandre Bezroutchko wrote:

> On Thu, Oct 18, I2012 at 12:51 PM, Joanna Rutkowska <

[Marek Marczykowski]

On 19.10.2012 00:55, Mark Reynolds wrote:
> I have only just begun this effort. I am characterizing FC dependencies
> into hard and not-so-hard, so that I can attack the hardest compatibility
> issues first. I wish I had more to offer, but it is still early days for
> Ubuntu template VM.

Feel free to ask any question you may have.

[Bruce Downs]

On Thu, Oct 18, 2012 at 5:02 PM, Marek Marczykowski
<marm...@invisiblethingslab.com> wrote:
> On 19.10.2012 00:55, Mark Reynolds wrote:
>> I have only just begun this effort. I am characterizing FC dependencies
>> into hard and not-so-hard, so that I can attack the hardest compatibility
>> issues first. I wish I had more to offer, but it is still early days for
>> Ubuntu template VM.
>
> Feel free to ask any question you may have.

First step (on fedora 17):
$ sudo yum install debootstrap

Right out of the gate I see this error.

$ debootstrap squeeze mydebroot/
E: Couldn't work out current architecture

On fedora (dpkg not being installed) you need to do:
$ sudo debootstrap --arch=amd64 squeeze mydebroot/

[Marek Marczykowski]

On 18.10.2012 06:08, abb wrote:
> On Sunday, October 7, 2012 11:09:50 PM UTC+2, Marek Marczykowski wrote:
>>
>> On 07.10.2012 20:50, abb wrote:
>>> Hi,
>>>
>>> Qubes wiki says qvm-dom0-network-via-netvm should be used to attach dom0
>> to
>>> the network. I don't find such script in my dom0, instead there is
>>> qubes-dom0-network-via-netvm. It also accepts up/down parameter, so I
>>> suppose it it the same but docs are outdated.
>>>
>>> When I try using it, it executes without errors, but networking does not
>>> work.
>>
>> (...)
>>
>> Indeed it isn't working now... I will investigate it, thanks for the
>> report.
>>
>
> Here is a workaround for issue #660. Attached is a patch to
> qubes-dom0-network-via-netvm to fix dom0-side. Now
> qubes-dom0-network-via-netvm up/down work and there is L2 connectivity
> between dom0 and netvm.
>
> I don't have a patch for netvm, the following needs to be done manually:
> ifconfig vif0.0 10.137.0.2/32
> ip route add 10.137.0.1/32 dev vif0.0
>
> After this is done, dom0 should have network connectivity.

The real problem was IP conflict between dom0 and netvm. From some time [1]
vif interface in netvm also have IP, calculated as VM IP with last octet "1".
In case when dom0 used 10.137.0.1, there was conflict...
Now I've fixed this by changing dom0 IP to 10.137.0.2.

[1]
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=303355a168285e62a22c29a94dc455b4fdc9606d

[abb]

On Thursday, October 18, 2012 8:14:02 PM UTC+2, Danny Fullerton wrote:

I might find some time to work on getting a NetBSD VM. Creating one and making it work doesn't seem to be a big challenge but I'm not quite sure how to integrate this in the build process. 

Any info on this? 

Danny, have you had time to work on integrating NetBSD into Qubes? Any progress/ideas?