[OE-core] runqemu + dhcp server

[Patrick Ohly]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-recipes-connectivity-enable-native-bind-and-dhcp.patch
Type: text/x-patch
Size: 3825 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150407/9c031e52/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-runqemu-automatically-run-DHCP-server.patch
Type: text/x-patch
Size: 6400 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150407/9c031e52/attachment-0005.bin>