launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

I just spent a few hours debugging strange network behaviour, which
turned out to be due to a DNS packet storm, with several dnsmasq
processes talking furiously to each other and to my router.  The root
cause of this seems to be that setuplxc modifies my dhclient.conf to
add 10.0.3.1 as a DNS server.
<https://bugs.launchpad.net/ubuntu/+source/linux/+bug/956732>

It's the second time setuplxc has damaged something on my machine
which it had no good reason to be changing, the first being
<https://bugs.launchpad.net/launchpad/+bug/936817> that it also
scrambles your bzr identity.

I realize software has bugs, especially new software, and I'm not mad
with you.  But I do think there is something systematically wrong in
the way setuplxc changes the host machine.  It's a bit ridiculous that
attempting to create an isolated sandbox damages the host machine.

If setuplxc is meant to be run on (would-be) developers' laptops, and
if it wants to be run as root, it needs to be  careful what it
changes, and my impression is at the moment it is not.  I would like
to suggest you adopt these design rules for it:

 * don't actually change the host, if you can avoid it!  For instance,
I don't see why you would need to change the bzr user identity - ok,
perhaps check it, and if it's wrong, complain.  Similarly if a needed
package is missing, just say so and bail out.
 * tell the user what you're going to change and get their permission,
like rocketfuel-setup does
 * make the changes in a way they can be easily reversed, eg by
writing a new .d file
 * when you edit a config file, add a comment saying launchpad
setuplxc did it, and when
 * make it clearer in the source code what will be done on the host -
when I looked a few weeks ago it was very tangled and unclear

rocketfuel-setup does at least some of these, and given the complaints
about it over the years it would be nice if setuplxc can do at least
as much.

--
Martin