All of lore.kernel.org
 help / color / mirror / Atom feed
* runqemu + dhcp server
@ 2014-11-04  8:09 Patrick Ohly
  2014-11-05 10:29 ` Adrian Freihofer
  2014-11-05 16:29 ` Burton, Ross
  0 siblings, 2 replies; 9+ messages in thread
From: Patrick Ohly @ 2014-11-04  8:09 UTC (permalink / raw)
  To: openembedded-core

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

Hello!

Recently I built a custom image which depended on a DHCP server to
configure Ethernet. runqemu with tap for networking doesn't provide one
at the moment, so ssh logins did not work.

Instead of customizing images for runqemu, I think it would be better to
adapt runqemu and uses images as on the target device. Attached two
patches which work for me. Is that of interest for inclusion upstream?

I suppose more work is needed, in particular around how to enable or
disable this feature. Patching the .bb files also leads to a (to me)
strange QA error. See the comments in the patches for details.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



[-- Attachment #2: 0001-recipes-connectivity-enable-dhcp-native.patch --]
[-- Type: text/x-patch, Size: 1546 bytes --]

From 700304071404ed22c81e57c169ef50ef424b66bc Mon Sep 17 00:00:00 2001
From: Patrick Ohly <patrick.ohly@intel.com>
Date: Mon, 3 Nov 2014 17:37:20 +0100
Subject: [PATCH 1/3] recipes-connectivity: enable dhcp-native

This depends on bind-native. It is needed for running a user-space
dhcpd for qemu guests.

TODO: modifying bind_9.9.5.bb like this triggers an error:

ERROR: QA Issue: /work/tizen/yocto/poky/meta/recipes-connectivity/bind/bind_9.9.5.bb: Variable RPROVIDES is set as not being package specific, please fix this. [pkgvarcheck]

Need to fix this, but I don't know how. I don't see what triggers the
error.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 meta/recipes-connectivity/bind/bind_9.9.5.bb | 1 +
 meta/recipes-connectivity/dhcp/dhcp.inc      | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/meta/recipes-connectivity/bind/bind_9.9.5.bb b/meta/recipes-connectivity/bind/bind_9.9.5.bb
index ebd38eff..bcc1601 100644
--- a/meta/recipes-connectivity/bind/bind_9.9.5.bb
+++ b/meta/recipes-connectivity/bind/bind_9.9.5.bb
@@ -88,3 +88,4 @@ CONFFILES_${PN} = " \
 	${sysconfdir}/bind/db.root \
 	"
 
+BBCLASSEXTEND = "native"
diff --git a/meta/recipes-connectivity/dhcp/dhcp.inc b/meta/recipes-connectivity/dhcp/dhcp.inc
index 4949e02..a8ddff8 100644
--- a/meta/recipes-connectivity/dhcp/dhcp.inc
+++ b/meta/recipes-connectivity/dhcp/dhcp.inc
@@ -113,3 +113,5 @@ pkg_postrm_dhcp-client() {
         echo "Not removing ${localstatedir}/lib/dhcp as it is non-empty."
     fi
 }
+
+BBCLASSEXTEND = "native"
-- 
2.1.1


[-- Attachment #3: 0002-runqemu-automatically-run-DHCP-server.patch --]
[-- Type: text/x-patch, Size: 4575 bytes --]

From ecca5665e81b1a3e4de113b7a1af76d94d1f61ef Mon Sep 17 00:00:00 2001
From: Patrick Ohly <patrick.ohly@intel.com>
Date: Mon, 3 Nov 2014 17:42:19 +0100
Subject: [PATCH 2/3] runqemu: automatically run DHCP server

Some images are not able to configure their Ethernet based on the
"ip" kernel parameter, for example Tizen. Instead of having to
modify images, it is easier to provide what these images expect
and have a DHCP server running on the host.

At the moment, the modified scripts expect that "dhcp-native" was
built for the host. runqemu-ifup sets capabilities such that the dhcpd
can be run as normal user with just minimal privileges and then
runqemu-internal takes care of bringing the daemon up and taking it
down again. All dhcpd files are stored together with the tap lock file
under /tmp. dhcpd output goes to stdout.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 scripts/runqemu-ifup     | 20 ++++++++++++++++++++
 scripts/runqemu-internal | 43 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+)

diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup
index b5a3db9..0806c40 100755
--- a/scripts/runqemu-ifup
+++ b/scripts/runqemu-ifup
@@ -57,6 +57,14 @@ if [ ! -x "$TUNCTL" ]; then
 	exit 1
 fi
 
+# TODO: make dhcpd optional?
+DHCPD=$NATIVE_SYSROOT_DIR/usr/sbin/dhcpd
+if [ ! -x "$DHCPD" ]; then
+	# TODO (?): integrate into qemu-helper-native
+	echo "Error: Unable to find dhcpd binary in '$NATIVE_SYSROOT_DIR/usr/sbin', please bitbake dhcp-native"
+	exit 1
+fi
+
 TAP=`$TUNCTL -b $GROUP 2>&1`
 STATUS=$?
 if [ $STATUS -ne 0 ]; then
@@ -89,6 +97,15 @@ if [ ! -x "$IPTABLES" ]; then
 	exit 1
 fi
 
+SETCAP=`which setcap 2> /dev/null`
+if [ "x$SETCAP" = "x" ]; then
+	SETCAP=/sbin/setcap
+fi
+if [ ! -x "$SETCAP" ]; then
+	echo "$SETCAP cannot be executed"
+	exit 1
+fi
+
 n=$[ (`echo $TAP | sed 's/tap//'` * 2) + 1 ]
 $IFCONFIG addr add 192.168.7.$n/32 broadcast 192.168.7.255 dev $TAP
 $IFCONFIG link set dev $TAP up
@@ -103,4 +120,7 @@ echo 1 > /proc/sys/net/ipv4/ip_forward
 echo 1 > /proc/sys/net/ipv4/conf/$TAP/proxy_arp
 $IPTABLES -P FORWARD ACCEPT
 
+# allow running dhcpd as normal user
+$SETCAP cap_net_raw,cap_net_bind_service+ep $DHCPD
+
 echo $TAP
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 38745dd..3a9c0b4 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -172,6 +172,13 @@ else
                exit 1
         fi
 
+        DHCPD=$OECORE_NATIVE_SYSROOT/usr/sbin/dhcpd
+        if [ ! -x "$DHCPD" ]; then
+	    # TODO (?): integrate into qemu-helper-native
+            echo "Error: Unable to find dhcpd binary in '$NATIVE_SYSROOT_DIR/usr/sbin', please bitbake dhcp-native"
+            exit 1
+        fi
+
         POSSIBLE=`$IFCONFIG link | grep 'tap' | awk '{print $2}' | sed s/://`
         TAP=""
         LOCKFILE=""
@@ -222,6 +229,10 @@ else
         fi
 
         cleanup() {
+            # Ensure that we don't kill an unrelated process.
+            if [ ! -e "$DHCPPID" ] && [ -s $DHCPPID ] && ps $(cat $DHCPPID) | grep -q dhcpd; then
+                kill $(cat $DHCPPID)
+            fi
             if [ ! -e "$NOSUDO_FLAG" -a "$USE_PRECONF_TAP" = "no" ]; then
                 # Redirect stderr since we could see a LD_PRELOAD warning here if pseudo is loaded
                 # but inactive. This looks scary but is harmless
@@ -249,6 +260,38 @@ else
         n1=$(($n0 * 2 + 1))
         n2=$(($n1 + 1))
 
+        DHCPDIR=$LOCKFILE.dhcp
+        rm -rf $DHCPDIR
+        mkdir $DHCPDIR
+        DHCPCONF=$DHCPDIR/dhcpd.conf
+        DHCPLEASE=$DHCPDIR/dhcpd.leases
+        DHCPPID=$DHCPDIR/dhcpd.pid
+        cat >$DHCPCONF <<EOF
+option domain-name "localdomain";
+authoritative;
+
+# Basically forever...
+default-lease-time 60000;
+max-lease-time 60000;
+
+subnet 192.168.7.0 netmask 255.255.255.0 {
+  range 192.168.7.$n2 192.168.7.$n2;
+  option routers 192.168.7.$n1;
+}
+EOF
+        touch $DHCPLEASE
+        echo $DHCPD -d -cf $DHCPCONF -lf $DHCPLEASE -pf $DHCPPID $TAP
+        # TODO: where should output go?
+        $DHCPD -d -cf $DHCPCONF -lf $DHCPLEASE -pf $DHCPPID $TAP &
+        pid=$!
+        while [ ! -s $DHCPPID ]; do
+            sleep 1
+            if ! ps $pid | grep -q dhcpd; then
+                echo "$DHCPD terminated unexpectedly."
+                return 1
+            fi
+        done
+
         KERNEL_NETWORK_CMD="ip=192.168.7.$n2::192.168.7.$n1:255.255.255.0"
         QEMU_TAP_CMD="-net tap,vlan=0,ifname=$TAP,script=no,downscript=no"
         if [ "$KVM_ACTIVE" = "yes" ]; then
-- 
2.1.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: runqemu + dhcp server
  2014-11-04  8:09 runqemu + dhcp server Patrick Ohly
@ 2014-11-05 10:29 ` Adrian Freihofer
  2014-11-07 10:12   ` Patrick Ohly
  2014-11-05 16:29 ` Burton, Ross
  1 sibling, 1 reply; 9+ messages in thread
From: Adrian Freihofer @ 2014-11-05 10:29 UTC (permalink / raw)
  To: openembedded-core

[-- Attachment #1: Type: text/plain, Size: 4268 bytes --]

Hello Patrick

Personally I would prefer a slightly different implementation. I consider the 192.168.7.2 network interface as development, debugging and testing interface which should just work. This interface has to be ignored by NetworkManager / connman and so on otherwise things like NFS rootfs or image tests break. But I agree that the current poky implementation does not fit well for people who develop other connectivity solutions e.g. a network interfaces configured by DHCP. Things can become quite difficult if eth0 is used as 192.168.7.2 development interface in qemu but gets a DHCP based IP configuration on the productive image.
To address this I started to run qemu with more than one emulated network interface. (Some time ago I posted a patch which fixes two blockers to start qemu with more than one emulated NIC: YOCTO #6356.[1])
Note: On the target device there are some simple udev rules which assign reasonable names to the different network interfaces. This simplifies many use cases a lot. The applied network configuration just depends on the available interfaces which is what connman and latest NetworkManager support perfectly. The 192.168.7.2 interface configuration assigned by the kernel gets never touched.
On the development host I use a project specific implementation for the runqemu-gen-tapdevs script. It does not only create the tap devices as the original does. It creates different virtual networks which are connected to the additional interfaces emulated by qemu. On one of these networks there is a dhcp server running. The dhcp server is managed by the runqemu-gen-tapdevs script. On the long term we could have different implementations of the runqemu-gen-tapdevs script. For example one which creates two tap devices per qemu instance. One tap device is used for the 192.168.7.x network and the other tap device is part of a bridge where a dhcp server runs on and IP forwarding allows to connect to the Internet.
With current poky implementation this is not really possible. Virtual devices are always connected to the Internet. The default route is set to 192.168.7.1 and IP forwarding on the host is configured for emulated interfaces automagically. I assume this is what most people need and it should remain the default behavior of course. But it would be nice to have an option to start qemu with host connectivity only. Meaning IP forwarding is not started for 192.168.7.x networks and the default route is not assigned via kernel boot parameter.
By the way, where does your solution make use of the DHCP server? The eth0 IP configuration is assigned by kernel boot parameters in runqemu-internal. If this configuration gets changed later on the NFS rootfs will break...

Sorry for the long mail. Here is a summary of my proposal:
- Add patch _YOCTO #6356._
- Change runqemu scripts to provide a host-only connectivity option (Basically just skip some lines of code in runqemu-ifup)
- Provide a runqemu-gen-tapdevs variant which creates two tap devs per quemu instance (connect all qemu instances via bridge?)
- Start the DHCP server by runqemu-gen-tapdevs (on tap devs or on a bridge)
- If bridged: Enable IP forwarding for the bridge
- run qemu like: runqemu ... qemuparams="-net nic,model=virtio... -net tap, ..." to emulate two NICs

I would like to publish the generic parts of my solution when ready. 

Regards,
Adrian


On Tuesday 04 November 2014 09.09:07 Patrick Ohly wrote:
> Hello!
> 
> Recently I built a custom image which depended on a DHCP server to
> configure Ethernet. runqemu with tap for networking doesn't provide one
> at the moment, so ssh logins did not work.
> 
> Instead of customizing images for runqemu, I think it would be better to
> adapt runqemu and uses images as on the target device. Attached two
> patches which work for me. Is that of interest for inclusion upstream?
> 
> I suppose more work is needed, in particular around how to enable or
> disable this feature. Patching the .bb files also leads to a (to me)
> strange QA error. See the comments in the patches for details.
> 
> 



--------------------
Adrian Freihofer
Gschwaderweg 29
8610 Uster
043 497 84 01

--------
[1] http://patchwork.openembedded.org/patch/74397/

[-- Attachment #2: Type: text/html, Size: 11265 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: runqemu + dhcp server
  2014-11-04  8:09 runqemu + dhcp server Patrick Ohly
  2014-11-05 10:29 ` Adrian Freihofer
@ 2014-11-05 16:29 ` Burton, Ross
  2014-11-11 15:58   ` Patrick Ohly
  1 sibling, 1 reply; 9+ messages in thread
From: Burton, Ross @ 2014-11-05 16:29 UTC (permalink / raw)
  To: Patrick Ohly; +Cc: OE-core

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

Hi Patrick,

On 4 November 2014 08:09, Patrick Ohly <patrick.ohly@intel.com> wrote:

> Recently I built a custom image which depended on a DHCP server to
> configure Ethernet. runqemu with tap for networking doesn't provide one
> at the moment, so ssh logins did not work.
>
> Instead of customizing images for runqemu, I think it would be better to
> adapt runqemu and uses images as on the target device. Attached two
> patches which work for me. Is that of interest for inclusion upstream?
>

I've long been of the opinion that runqemu needs the ability to setup a
DHCP/DNS server for the guest, as whilst you can special-case qemu machines
and hard-code the relevant network configuration it doesn't help with
testing.  That said, I'm not convinced that dhcpd+bind is the right way
forward, something like dnsmasq (currently in meta-networking) might be
quicker to build and more flexible in this environment.

I suppose more work is needed, in particular around how to enable or
> disable this feature. Patching the .bb files also leads to a (to me)
> strange QA error. See the comments in the patches for details.
>

This is likely due to bind using PACKAGES_prepend instead of PACKAGES =+
(=+ is prepend), which messes up the native.bbclass magic.

Ross

[-- Attachment #2: Type: text/html, Size: 1956 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: runqemu + dhcp server
  2014-11-05 10:29 ` Adrian Freihofer
@ 2014-11-07 10:12   ` Patrick Ohly
  2014-11-10 21:57     ` Adrian Freihofer
  0 siblings, 1 reply; 9+ messages in thread
From: Patrick Ohly @ 2014-11-07 10:12 UTC (permalink / raw)
  To: openembedded-core

Adrian Freihofer <adrian.freihofer@...> writes:
> Personally I would prefer a slightly different implementation.
> I consider the 192.168.7.2 network interface as development, debugging
> and testing interface which should just work.

Agreed, and it doesn't work at the moment when the image has an Ethernet
configuration mechanism that wasn't adapted to use the ip kernel parameter. 
What you are proposing goes beyond just fixing that. I don't have any strong
opinion about the right way forward.

> By the way, where does your solution make use of the DHCP server?

When Connman starts up, it finds eth0 and obtains an IP address for it via
DHCP. Without the DHCP server, the guest ends up without an IP address. I
have not checked if the ip parameter was ever used.

Note that this is what the default Tizen Connman config does, not what Poky
would do when building and installing Connman. The whole point was the
ability to use production images without special tweaks. 

> The 
> eth0 IP configuration is assigned by kernel boot parameters in
> runqemu-internal. If this configuration gets changed later on the NFS 
> rootfs will break...

I haven't tried NFS rootfs. My hope is that it would still work because the
ip parameter and the DHCP server assign the same IP address and thus nothing
changes inside the guest when switching from one to the other.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: runqemu + dhcp server
  2014-11-07 10:12   ` Patrick Ohly
@ 2014-11-10 21:57     ` Adrian Freihofer
  2015-02-17 10:34       ` Patrick Ohly
  2015-04-07 15:57       ` Patrick Ohly
  0 siblings, 2 replies; 9+ messages in thread
From: Adrian Freihofer @ 2014-11-10 21:57 UTC (permalink / raw)
  To: openembedded-core

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]

On Friday 07 November 2014 10.12:02 Patrick Ohly wrote:
> Adrian Freihofer <adrian.freihofer@...> writes:
> > Personally I would prefer a slightly different implementation.
> > I consider the 192.168.7.2 network interface as development, debugging
> > and testing interface which should just work.
> 
> Agreed, and it doesn't work at the moment when the image has an Ethernet
> configuration mechanism that wasn't adapted to use the ip kernel parameter. 
> What you are proposing goes beyond just fixing that. I don't have any strong
> opinion about the right way forward.
> 
> > By the way, where does your solution make use of the DHCP server?
> 
> When Connman starts up, it finds eth0 and obtains an IP address for it via
> DHCP. Without the DHCP server, the guest ends up without an IP address. I
> have not checked if the ip parameter was ever used.
> 
> Note that this is what the default Tizen Connman config does, not what Poky
> would do when building and installing Connman. The whole point was the
> ability to use production images without special tweaks. 
> 
> > The 
> > eth0 IP configuration is assigned by kernel boot parameters in
> > runqemu-internal. If this configuration gets changed later on the NFS 
> > rootfs will break...
> 
> I haven't tried NFS rootfs. My hope is that it would still work because the
> ip parameter and the DHCP server assign the same IP address and thus nothing
> changes inside the guest when switching from one to the other.
> 
I see, the patch you are working on will provide just another option to get eth0 configured. This would definitely be an improvement.
Did you ever run the automated image tests? If I remember correctly the image tests are somehow related to the current implementation of the network configuration. At least the tests require a hostname starting with "qemu" and probably they run from NFS rootfs.
Would be nice, if you get the DHCP based network configuration fulfilling these requirements. An alternative approach is implemented in systemd networkd. I guess it does not touch interfaces which are already configured e.g. by kernel boot parameters. This could be done in connman as well. It would allow you to run the productive image in qemu.-- 

--------------------
Neratec Solutions AG
Postfach 83, CH-8608 Bubikon, Switzerland

adrian.freihofer@neratec.com
Direct: +41 55 253 2083
Office: +41 55 253 2000
www.neratec.com[1]

--------
[1] www.neratec.com

[-- Attachment #2: Type: text/html, Size: 8790 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: runqemu + dhcp server
  2014-11-05 16:29 ` Burton, Ross
@ 2014-11-11 15:58   ` Patrick Ohly
  0 siblings, 0 replies; 9+ messages in thread
From: Patrick Ohly @ 2014-11-11 15:58 UTC (permalink / raw)
  To: Burton, Ross; +Cc: OE-core

On Wed, 2014-11-05 at 16:29 +0000, Burton, Ross wrote:

> On 4 November 2014 08:09, Patrick Ohly <patrick.ohly@intel.com> wrote:
>         Recently I built a custom image which depended on a DHCP
>         server to
>         configure Ethernet. runqemu with tap for networking doesn't
>         provide one
>         at the moment, so ssh logins did not work.
>         
>         Instead of customizing images for runqemu, I think it would be
>         better to
>         adapt runqemu and uses images as on the target device.
>         Attached two
>         patches which work for me. Is that of interest for inclusion
>         upstream?
>         
> 
> 
> I've long been of the opinion that runqemu needs the ability to setup
> a DHCP/DNS server for the guest, as whilst you can special-case qemu
> machines and hard-code the relevant network configuration it doesn't
> help with testing.  That said, I'm not convinced that dhcpd+bind is
> the right way forward, something like dnsmasq (currently in
> meta-networking) might be quicker to build and more flexible in this
> environment.

I was looking for a solution that works inside the Poky repository,
without external dependencies, and thus only depends on oe-core. Are you
suggesting that dnsmasq should be moved into oe-core?

What extra flexibility would you like see provided on the host side? All
I needed was the DHCP server, so bind+dhcpd fit the bill for me.
Compilation speed didn't seem like a big deal.

Handing DNS settings to the DHCP client is missing in the patch, but
could be added also when using bind+dhcpd. It's a bit harder to do in
the general case than with dnsmasq, because runqemu-internal somehow
needs to determine where it can find a DNS server in order to configure
dhcpd, whereas dnsmasq itself could act as DNS proxy.

When using dhcpd, would hard-coding a well-known one like Google's
8.8.8.8 as default with an explicit override via env variable be
acceptable?

Either way, what would be the right way to integrate this from a user
perspective? Should running the DHCP server (whichever one it is) be
done by default? Always or should there be an option to turn it on or
off? How?

>         I suppose more work is needed, in particular around how to
>         enable or
>         disable this feature. Patching the .bb files also leads to a
>         (to me)
>         strange QA error. See the comments in the patches for details.
> 
> This is likely due to bind using PACKAGES_prepend instead of PACKAGES
> =+ (=+ is prepend), which messes up the native.bbclass magic.

That's right, replacing _prepend with =+ fixed the problem.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: runqemu + dhcp server
  2014-11-10 21:57     ` Adrian Freihofer
@ 2015-02-17 10:34       ` Patrick Ohly
  2015-02-17 16:24         ` Adrian Freihofer
  2015-04-07 15:57       ` Patrick Ohly
  1 sibling, 1 reply; 9+ messages in thread
From: Patrick Ohly @ 2015-02-17 10:34 UTC (permalink / raw)
  To: Adrian Freihofer; +Cc: openembedded-core

On Mon, 2014-11-10 at 22:57 +0100, Adrian Freihofer wrote:
> > I haven't tried NFS rootfs. My hope is that it would still work because the
> > ip parameter and the DHCP server assign the same IP address and thus nothing
> > changes inside the guest when switching from one to the other.
> > 
> 
> I see, the patch you are working on will provide just another option
> to get eth0 configured. This would definitely be an improvement.

I had to put this aside for a while, but I'm still interested in getting
this merged.

> Did you ever run the automated image tests? If I remember correctly
> the image tests are somehow related to the current implementation of
> the network configuration. At least the tests require a hostname
> starting with "qemu" and probably they run from NFS rootfs.

Where do I find more information about these tests, in particular how to
run them?

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#testing-packages-with-ptest describes how to add tests to an image, but leaves it open how one invokes ptest-runner. What you describe sounds like a mechanism built on top of that which automatically boots up a machine and captures the output of ptest-runner.

> Would be nice, if you get the DHCP based network configuration
> fulfilling these requirements. An alternative approach is implemented
> in systemd networkd. I guess it does not touch interfaces which are
> already configured e.g. by kernel boot parameters. This could be done
> in connman as well. It would allow you to run the productive image in
> qemu.

There might be also other improvements. For example, I just booted a
core-image-minimal with systemd as init with runqemu. eth0 is
configured, but /etc/resolv.conf is missing, so ptests like the one for
wget fail because www.google.com cannot be resolved.

This was without the DHCP server patches. My expectation is that
bringing up eth0 with DHCP-supplied information about DNS servers would
have created (or could be made to create) resolv.conf.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: runqemu + dhcp server
  2015-02-17 10:34       ` Patrick Ohly
@ 2015-02-17 16:24         ` Adrian Freihofer
  0 siblings, 0 replies; 9+ messages in thread
From: Adrian Freihofer @ 2015-02-17 16:24 UTC (permalink / raw)
  To: Patrick Ohly; +Cc: openembedded-core

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

On Tuesday 17 February 2015 11.34:14 you wrote:
> On Mon, 2014-11-10 at 22:57 +0100, Adrian Freihofer wrote:
> > > I haven't tried NFS rootfs. My hope is that it would still work because the
> > > ip parameter and the DHCP server assign the same IP address and thus nothing
> > > changes inside the guest when switching from one to the other.
> > > 
> > 
> > I see, the patch you are working on will provide just another option
> > to get eth0 configured. This would definitely be an improvement.
> 
> I had to put this aside for a while, but I'm still interested in getting
> this merged.
> 
> > Did you ever run the automated image tests? If I remember correctly
> > the image tests are somehow related to the current implementation of
> > the network configuration. At least the tests require a hostname
> > starting with "qemu" and probably they run from NFS rootfs.
> 
> Where do I find more information about these tests, in particular how to
> run them?
On 2014-05-29 I got the following hint from Saul Wold:
"You can try the sanity testing locally by setting IMAGETEST in local.conf (please look at local.conf for details)."
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=6356)[1]
> 
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#testing-packages-with-ptest describes how to add tests to an image, but leaves it open how one invokes ptest-runner. What you describe sounds like a mechanism built on top of that which automatically boots up a machine and captures the output of ptest-runner.
> 
> > Would be nice, if you get the DHCP based network configuration
> > fulfilling these requirements. An alternative approach is implemented
> > in systemd networkd. I guess it does not touch interfaces which are
> > already configured e.g. by kernel boot parameters. This could be done
> > in connman as well. It would allow you to run the productive image in
> > qemu.
> 
> There might be also other improvements. For example, I just booted a
> core-image-minimal with systemd as init with runqemu. eth0 is
> configured, but /etc/resolv.conf is missing, so ptests like the one for
> wget fail because www.google.com cannot be resolved.
> 
> This was without the DHCP server patches. My expectation is that
> bringing up eth0 with DHCP-supplied information about DNS servers would
> have created (or could be made to create) resolv.conf.
> 
> 


--------
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=6356

[-- Attachment #2: Type: text/html, Size: 9703 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: runqemu + dhcp server
  2014-11-10 21:57     ` Adrian Freihofer
  2015-02-17 10:34       ` Patrick Ohly
@ 2015-04-07 15:57       ` Patrick Ohly
  1 sibling, 0 replies; 9+ messages in thread
From: Patrick Ohly @ 2015-04-07 15:57 UTC (permalink / raw)
  To: Adrian Freihofer; +Cc: openembedded-core

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

On Mon, 2014-11-10 at 22:57 +0100, Adrian Freihofer wrote:
> Did you ever run the automated image tests? If I remember correctly
> the image tests are somehow related to the current implementation of
> the network configuration. At least the tests require a hostname
> starting with "qemu" and probably they run from NFS rootfs.

After investigating this, I found that testimage.bbclass itself does not
support NFS rootfs. It is only runqemu which (in combination with
runqemu-extract-sdk) can run in NFS mode. That mode works in combination
with a running dhcpd, I tested that.

> Would be nice, if you get the DHCP based network configuration
> fulfilling these requirements. An alternative approach is implemented
> in systemd networkd. I guess it does not touch interfaces which are
> already configured e.g. by kernel boot parameters. This could be done
> in connman as well. It would allow you to run the productive image in
> qemu.

I'm starting to agree here, for two reasons: one is that I am working
less with genuine Tizen these days (so the need for having a DHCP server
is less urgent), the other is that I noticed a problem with usermode
dhcp via capabilities.

The problem is that setting capabilities disables the ORIGIN components
in RPATH (due to security concerns, see http://blog.tinola.com/?e=7),
causing the binary to pick up libcrypto from the host, which happens
to work but is not guaranteed. On OpenSUSE it leads to a warning
about "libcrypto.so.1.0.0: no version information available".

I tried restoring absolute RPATH in the dhcpd binary, but that failed
because apparently chrpath can only shorten the search path: once
chrpath.bbclass has replaced the longer path with the one using ORIGIN,
that cannot be undone.

So at this point I don't have a good solution. The patch happens to
work, but clearly is not ready for inclusion and might never be. I'm
attaching updated patches anyway, because some more work was needed to
get bind compiled natively again after the "prevent accidental usage of
config scripts patch".

Perhaps dhcpd should get brought up together with tap0 in runqemu-ifup
and kept running, instead of starting it on demand in runqemu-internal?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



[-- Attachment #2: 0001-recipes-connectivity-enable-native-bind-and-dhcp.patch --]
[-- Type: text/x-patch, Size: 3825 bytes --]

From f20aa3fd411486d2df6ecbfc5430f03c79bf6989 Mon Sep 17 00:00:00 2001
From: Patrick Ohly <patrick.ohly@intel.com>
Date: Mon, 3 Nov 2014 17:37:20 +0100
Subject: [PATCH 1/2] recipes-connectivity: enable native bind and dhcp

This depends on bind-native. It is needed for running a user-space
dhcpd for qemu guests. The bind .pc patch had to be updated such
that it prefers the .pc file, because during native compilation
the xml2-config script is found but intentionally not usable
to catch accidental usages of it. This worked for target compilation
because there the script gets moved into a crossscripts directory
such that it was not found.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 ...d-crosscripts-search-path-for-xml2-config.patch | 31 ++++++++++++----------
 meta/recipes-connectivity/bind/bind_9.9.5.bb       |  1 +
 meta/recipes-connectivity/dhcp/dhcp.inc            |  2 ++
 3 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/meta/recipes-connectivity/bind/bind/bind-add-crosscripts-search-path-for-xml2-config.patch b/meta/recipes-connectivity/bind/bind/bind-add-crosscripts-search-path-for-xml2-config.patch
index 4f1a3f8..6171c1f 100644
--- a/meta/recipes-connectivity/bind/bind/bind-add-crosscripts-search-path-for-xml2-config.patch
+++ b/meta/recipes-connectivity/bind/bind/bind-add-crosscripts-search-path-for-xml2-config.patch
@@ -8,28 +8,31 @@ bin folder is not copied to sysroot so the test was failing. Added another
 condition to test libxml-2.0.pc which is present in lib folder. Used pkg-config
 to get libs and cflags information.
 
+[Patrick Ohly: swaped checks to look for .pc file first. xml2-config, if present,
+is intentionally returning garbage to catch recipes which continue using it.]
+
 Upstream-Status: Inappropriate [ openembedded specific ]
 
 Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
 Signed-off-by: Noor Ahsan <noor_ahsan@mentor.com>
+Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
 ---
  configure.in | 3 +++
  1 file changed, 3 insertions(+)
 
-diff --git a/configure.in b/configure.in
-index 3d04f4c..6032f67 100644
---- a/configure.in
-+++ b/configure.in
-@@ -1433,6 +1433,9 @@ case "$use_libxml2" in
- 		if test -f "$use_libxml2/bin/xml2-config" ; then
- 			libxml2_libs=`$use_libxml2/bin/xml2-config --libs`
- 			libxml2_cflags=`$use_libxml2/bin/xml2-config --cflags`
-+		elif test -f "$use_libxml2/lib/pkgconfig/libxml-2.0.pc" ; then
+Index: bind-9.9.5/configure.in
+===================================================================
+--- bind-9.9.5.orig/configure.in
++++ bind-9.9.5/configure.in
+@@ -1430,7 +1430,10 @@ case "$use_libxml2" in
+ 		esac
+ 		;;
+ 	*)
+-		if test -f "$use_libxml2/bin/xml2-config" ; then
++		if test -f "$use_libxml2/lib/pkgconfig/libxml-2.0.pc" ; then
 +			libxml2_libs=`pkg-config libxml-2.0 --libs`
 +			libxml2_cflags=`pkg-config libxml-2.0 --cflags`
++		elif test -f "$use_libxml2/bin/xml2-config" ; then
+ 			libxml2_libs=`$use_libxml2/bin/xml2-config --libs`
+ 			libxml2_cflags=`$use_libxml2/bin/xml2-config --cflags`
  		fi
- 		;;
- esac
--- 
-1.9.1
-
diff --git a/meta/recipes-connectivity/bind/bind_9.9.5.bb b/meta/recipes-connectivity/bind/bind_9.9.5.bb
index e34cded..6bbc2be 100644
--- a/meta/recipes-connectivity/bind/bind_9.9.5.bb
+++ b/meta/recipes-connectivity/bind/bind_9.9.5.bb
@@ -103,3 +103,4 @@ CONFFILES_${PN} = " \
 	${sysconfdir}/bind/db.root \
 	"
 
+BBCLASSEXTEND = "native"
diff --git a/meta/recipes-connectivity/dhcp/dhcp.inc b/meta/recipes-connectivity/dhcp/dhcp.inc
index 6ced775..b4b4384 100644
--- a/meta/recipes-connectivity/dhcp/dhcp.inc
+++ b/meta/recipes-connectivity/dhcp/dhcp.inc
@@ -109,3 +109,5 @@ pkg_postrm_dhcp-client() {
         echo "Not removing ${localstatedir}/lib/dhcp as it is non-empty."
     fi
 }
+
+BBCLASSEXTEND = "native"
-- 
1.8.4.5


[-- Attachment #3: 0002-runqemu-automatically-run-DHCP-server.patch --]
[-- Type: text/x-patch, Size: 6400 bytes --]

From 70b8a99bfbfb8c586e36545afd47aa3990d8f547 Mon Sep 17 00:00:00 2001
From: Patrick Ohly <patrick.ohly@intel.com>
Date: Mon, 3 Nov 2014 17:42:19 +0100
Subject: [PATCH 2/2] runqemu: automatically run DHCP server

Some images are not able to configure their Ethernet based on the
"ip" kernel parameter, for example Tizen. Instead of having to
modify images, it is easier to provide what these images expect
and have a DHCP server running on the host.

At the moment, the modified scripts expect that "dhcp-native" was
built for the host. runqemu-ifup sets capabilities such that the dhcpd
can be run as normal user with just minimal privileges and then
runqemu-internal takes care of bringing the daemon up and taking it
down again. All dhcpd files are stored together with the tap lock file
under /tmp. dhcpd output goes to stdout.

This approach needs further work: due to the additional capabilities,
the ORIGIN RPATH gets ignored, causing dhcpd to run with the host's
libcrypto. See comment in runqemu-ifup for details.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 scripts/runqemu-ifup     | 36 +++++++++++++++++++++++++++
 scripts/runqemu-internal | 65 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 101 insertions(+)

diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup
index b5a3db9..f581334 100755
--- a/scripts/runqemu-ifup
+++ b/scripts/runqemu-ifup
@@ -57,6 +57,14 @@ if [ ! -x "$TUNCTL" ]; then
 	exit 1
 fi
 
+# TODO: make dhcpd optional?
+DHCPD=$NATIVE_SYSROOT_DIR/usr/sbin/dhcpd
+if [ ! -x "$DHCPD" ]; then
+	# TODO (?): integrate into qemu-helper-native
+	echo "Error: Unable to find dhcpd binary in '$NATIVE_SYSROOT_DIR/usr/sbin', please bitbake dhcp-native"
+	exit 1
+fi
+
 TAP=`$TUNCTL -b $GROUP 2>&1`
 STATUS=$?
 if [ $STATUS -ne 0 ]; then
@@ -89,6 +97,15 @@ if [ ! -x "$IPTABLES" ]; then
 	exit 1
 fi
 
+SETCAP=`which setcap 2> /dev/null`
+if [ "x$SETCAP" = "x" ]; then
+	SETCAP=/sbin/setcap
+fi
+if [ ! -x "$SETCAP" ]; then
+	echo "$SETCAP cannot be executed"
+	exit 1
+fi
+
 n=$[ (`echo $TAP | sed 's/tap//'` * 2) + 1 ]
 $IFCONFIG addr add 192.168.7.$n/32 broadcast 192.168.7.255 dev $TAP
 $IFCONFIG link set dev $TAP up
@@ -103,4 +120,23 @@ echo 1 > /proc/sys/net/ipv4/ip_forward
 echo 1 > /proc/sys/net/ipv4/conf/$TAP/proxy_arp
 $IPTABLES -P FORWARD ACCEPT
 
+# Allow running dhcpd as normal user: let the process obtain
+# the necessary capabilities from the file. This causes ld.so
+# to ignore the relative $ORIGIN RPATH, so we have to add
+# back absolute paths.
+#
+# Setting capabilities disables the ORIGIN components in RPATH
+# (due to security concerns, see http://blog.tinola.com/?e=7), causing
+# the binary to pick up libcrypto from the host, which happens
+# to work but is not guaranteed. On OpenSUSE it leads to a warning
+# about "libcrypto.so.1.0.0: no version information available".
+#
+# TODO: somehow install a copy of dhcpd with absolute paths
+#
+# Note that adding the absolute paths back here does not work because
+# apparently chrpath can only shorten the search path: once
+# chrpath.bbclass has replaced the longer path with the one using
+# ORIGIN, that cannot be undone.
+$SETCAP cap_net_bind_service,cap_net_raw+ep $DHCPD
+
 echo $TAP
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 2db5566..fc1a5e6 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -111,6 +111,24 @@ if [ -z "$QEMUIFDOWN" -o ! -x "$QEMUIFDOWN" ]; then
        exit 1
 fi
 
+GETCAP=`PATH=$PATH:/sbin:/usr/sbin which getcap 2> /dev/null`
+if [ "x$GETCAP" = "x" ]; then
+	GETCAP=/sbin/getcap
+fi
+if [ ! -x "$GETCAP" ]; then
+	echo "$GETCAP cannot be executed"
+	exit 1
+fi
+
+SETCAP=`PATH=$PATH:/sbin:/usr/sbin which setcap 2> /dev/null`
+if [ "x$SETCAP" = "x" ]; then
+	SETCAP=/sbin/setcap
+fi
+if [ ! -x "$SETCAP" ]; then
+	echo "$SETCAP cannot be executed"
+	exit 1
+fi
+
 NFSRUNNING="false"
 
 #capture original stty values
@@ -179,6 +197,17 @@ else
                exit 1
         fi
 
+        DHCPD_CAPABILITIES="cap_net_bind_service,cap_net_raw+ep"
+        DHCPD=$OECORE_NATIVE_SYSROOT/usr/sbin/dhcpd
+        if [ ! -x "$DHCPD" ]; then
+            echo "Error: Unable to find dhcpd binary in '$NATIVE_SYSROOT_DIR/usr/sbin', please bitbake qemu-helper-native"
+            exit 1
+        fi
+        if [ "$($GETCAP "$DHCPD" | sed -e 's/.* = //')" != $DHCPD_CAPABILITIES ]; then
+	    echo "Error: $DHCPD does not have the required capabilities to run as non-root. Run sudo $SETCAP $DHCPD_CAPABILITIES $DHCPD"
+	    exit 1
+        fi
+
         POSSIBLE=`$IFCONFIG link | grep 'tap' | awk '{print $2}' | sed s/://`
         TAP=""
         LOCKFILE=""
@@ -229,6 +258,10 @@ else
         fi
 
         cleanup() {
+            # Ensure that we don't kill an unrelated process.
+            if [ ! -e "$DHCPPID" ] && [ -s $DHCPPID ] && ps $(cat $DHCPPID) | grep -q dhcpd; then
+                kill $(cat $DHCPPID)
+            fi
             if [ ! -e "$NOSUDO_FLAG" -a "$USE_PRECONF_TAP" = "no" ]; then
                 # Redirect stderr since we could see a LD_PRELOAD warning here if pseudo is loaded
                 # but inactive. This looks scary but is harmless
@@ -256,6 +289,38 @@ else
         n1=$(($n0 * 2 + 1))
         n2=$(($n1 + 1))
 
+        DHCPDIR=$LOCKFILE.dhcp
+        rm -rf $DHCPDIR
+        mkdir $DHCPDIR
+        DHCPCONF=$DHCPDIR/dhcpd.conf
+        DHCPLEASE=$DHCPDIR/dhcpd.leases
+        DHCPPID=$DHCPDIR/dhcpd.pid
+        cat >$DHCPCONF <<EOF
+option domain-name "localdomain";
+authoritative;
+
+# Basically forever...
+default-lease-time 60000;
+max-lease-time 60000;
+
+subnet 192.168.7.0 netmask 255.255.255.0 {
+  range 192.168.7.$n2 192.168.7.$n2;
+  option routers 192.168.7.$n1;
+}
+EOF
+        touch $DHCPLEASE
+        echo $DHCPD -d -cf $DHCPCONF -lf $DHCPLEASE -pf $DHCPPID $TAP
+        # TODO: where should output go?
+        $DHCPD -d -cf $DHCPCONF -lf $DHCPLEASE -pf $DHCPPID $TAP &
+        pid=$!
+        while [ ! -s $DHCPPID ]; do
+            sleep 1
+            if ! ps $pid | grep -q dhcpd; then
+                echo "$DHCPD terminated unexpectedly."
+                return 1
+            fi
+        done
+
         KERNEL_NETWORK_CMD="ip=192.168.7.$n2::192.168.7.$n1:255.255.255.0"
         QEMU_TAP_CMD="-net tap,vlan=0,ifname=$TAP,script=no,downscript=no"
         if [ "$KVM_ACTIVE" = "yes" ]; then
-- 
1.8.4.5


^ permalink raw reply related	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-04-07 15:57 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-04  8:09 runqemu + dhcp server Patrick Ohly
2014-11-05 10:29 ` Adrian Freihofer
2014-11-07 10:12   ` Patrick Ohly
2014-11-10 21:57     ` Adrian Freihofer
2015-02-17 10:34       ` Patrick Ohly
2015-02-17 16:24         ` Adrian Freihofer
2015-04-07 15:57       ` Patrick Ohly
2014-11-05 16:29 ` Burton, Ross
2014-11-11 15:58   ` Patrick Ohly

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.