Dear networking wizards,

This is a bit of a self-reflexive mail, but I hope some of you might
have some input...

In writing netconf[0], we are having a bit of a problem with the
test suite, since many of netconf's operations require root rights
(e.g. interface manipulation with /bin/ip). In addition, a test
suite manipulating the network configuration of the running machine
is not really something I feel comfortable with.

0. http://netconf.alioth.debian.org

So I am trying to come up with alternative plans, of which there are
three:

1. do not fail tests that need root rights when run as non-root
2. set up a VDE network (which still requires root rights)
3. write a mock /bin/ip which pretends to be doing what it'd be doing

None of these three is satisfactory. (1) provides incomplete test
coverage unless run by root, which is not going to be done very
often, (2) can be combined with (1) but still puts the host machine
in danger of losing connectivity, and (3) just sounds terrible,
especially when other stuff, like dhclient or wpa_supplicant come
into play.

Of course, I am asking a bit much, but maybe you guys have some
input that could help us move along?

What I really want is some context handler that can emulate
a complete network and process stack for my test scripts, let
a normal user modify anything they want, but not touch anything on
the actual system. Sort of like database transactions. I think I may
be out of luck though, no?

--=20
martin | http://madduck.net/ | http://two.sentenc.es/
=20
"you don't sew with a fork, so I see no reason
 to eat with knitting needles."
                               -- miss piggy, on eating chinese food
=20
spamtraps: madduck.bogus@madduck.net
[ message continues ]

[...]

Have you considering running the tests in User-Mode Linux or some
other kind of virtualised environment?

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
--

[ message continues ]

also sprach Ben Hutchings <bhutchings@solarflare.com> [2008.06.03.1205 +020=

Yes, but that would require root rights as well, and quite a lot of
setup, making it pretty unlikely that passerby developers would run
tests, or allowing me to run the tests automatically on build
daemons.

--=20
martin | http://madduck.net/ | http://two.sentenc.es/
=20
"work consists of whatever a body is obliged to do.
 play consists of whatever a body is not obliged to do."
                                                         -- mark twain
=20
spamtraps: madduck.bogus@madduck.net
[ message continues ]

I don't believe that's the case for UML.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
--

[ message continues ]

also sprach Ben Hutchings <bhutchings@solarflare.com> [2008.06.03.1247 +020=

You're right. I spent some time with UML yesterday and got it to the
point where it can run an command in a UML and report back the
status code without requiring any setup or root rights. If you're
interested:

  http://git.debian.org/?p=3Dnetconf/netconf.git;a=3Dtree;f=3Duml;hb=3Dumlt=
est

Now I need to figure out how to set up uml_switch as a user such
that I can have two or three interfaces within the UML on the same
network segment.

Right now, my problem is that if eth0-2 have 1.2.3.1-3 assigned to
them, pinging 1.2.3.2 from 1.2.3.1 will make Linux route the packets
via loopback. I need to figure out how to make them be put on the
wire (which is uml_switch in this case).

--=20
martin | http://madduck.net/ | http://two.sentenc.es/
=20
"whale feces or working at microsoft? i would probably be the whale
 feces researcher. salt air and whale flatulence; what
 could go wrong?"
             -- michael moyer, executive editor of _popular science_
=20
spamtraps: madduck.bogus@madduck.net
[ message continues ]

Hi,


The best way would be to use the Hurd, and write a network device
emulator (which can be modified without messing up actual network
devices).  But I suppose that's not an option. ;-)

As a second option, I'd go for qemu.  It can be run as non-root and
communicate about its test results over the serial port (connected to
stdout).  However, building a qemu image takes a long time, and I think

Qemu does all that, it emulates a whole computer with it. :-)


You can do all the setup automatically, so passerby developers don't
need to know how to do it.  However, the root rights (or, in case of
qemu, the heavy setup process) does probably make it impractical to do
it on a buildd, for example.

An option would be to create a dummy network device of the type I
described for the Hurd, but for Linux, and package that in a separate
package.  Netconf can build-depend on it, so it is installed (and can
make sure it is available for normal users).

However, I don't think Linux allows network interfaces to tell that
normal users may modify them...

Thanks,
Bas

--=20
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
[ message continues ]