Thank you very much for fast reponse :) On Thursday 14 December 2006 13:19, Ludovico Gardenghi wrote: > Hi. Renzo Davoli, the main VDE author, asked Guido and me to create a > new package for VDE2. There was no recent activity on the vde package so > we went on with the packaging.
Yes, there was a problem with VDE 2.0.x version and it didn't work correctly if the separate programs was started with different privileges. I.e. the vde_switch as root, the slirpvde as user. My modifications allow to start VDE components with anybody who are in vde2-net group. The trick is to start each components' sockets with 660 mode. If some user belongs to vde2-net group, it can connect to the socket. I needed some additional modifications for upstream (the 070-mode_for_comm_socket.patch file). I'll be glad if the patch will be applied to the upstream. I didn't want to release the vde2 package which doesn't support group-based privileges, so I delayed my work... > We have no problems in leaving the maintenance of VDE packages to you > and, if needed, in adding you to the members of pkg-vsquare. I think the better way is to put my patches to upstream. I see the pkg-vsquare project is very reasonable, and I think our work can be merged. > > * Does the vde2 package interfere with vde package? > > As for now, yes. Binaries have the same names and places in vde and > vde2; in fact we added a Conflict in vde2 against vde. We don't see this > as a problem, because vde2 has complete backwards compatibility with vde > and it't much more reliable and bug-free. 1.x series of VDE should not > be used anymore. The real question is: should we remove vde package from etch or not? Unfortunately, the etch is frozen now, so at least we can leave the VDE 1.x in Debian stable... I've provided the transitioning package: Package: vde Architecture: all Depends: vde2 Description: transitional dummy package which can be safely removed Dummy package to upgrade to the new vde2 package. I think it might be a smooth way for upgrade VDE 1.x to the 2.x, but as far as etch is frozen, I'm afraid that the upgrade shouldn't be forced. > > * Does it contain some additional patches? > > Being the authors of VDE we decided to put everything in the main CVS > tree: we see no point in having debian-specific patches. So I'd like to list my patches and explain why I created them: 010-fhs_compatibility.patch: vdetap.c prints the path to shared library as /usr/local/lib/libvdetap.so. It should be /usr/lib/vde2/libvdetap.so 030-rtld_next.patch: The libvdetap shouldn't call syscalls! Instead of this, it should call next function in dynamic library symbol list. It is only way to make libvdetap compatible with other dynamic library wrappers, like fakeroot or fakechroot. Worse, using pure syscalls makes VDE not portable to other systems than Linux! 040-missing_includes.patch: I think it is not necessary now. 050-sigs_on_non_i386_archs.patch: The VDE is not portable to non-i386 architectures! This patch is necessary for alpha and arm, AFAIR. 060-vdeqemu_cleanup_after_error.patch: The vdeq does not clean up after some errors. 070-mode_for_comm_socket.patch: The patch for allowing to use group-based privileges. The patch also provides "-m" option for vdeq and vdetap. 080-daemonize_with_detach.patch: The vde_switch and slirpvde don't detach from terminal. It is the must for daemons, because it hangs the start up scripts otherwise. 090-slirpvde_pidfile.patch: The slirpvde doesn't create pidfile. > > * Does it provide /etc/network/interfaces support? > > No. I took a quick look to your support and it seems complete and > useful. I think it should be included in the official vde2 package. The hints how to use this interface are in README.Debian file. > > * Does it support non-root users? > > I'm not sure I've fully understood this question. Strictly speaking, > vde2 never needs root access. The only case it may be needed is when you > want to connect a vde_switch to a tap interface (I agree that's often > the case, but not always) and nobody created a persistent tap interfaces > for you. But also in this case you can create a persistent tap interface > with tunctl with the correct owner and let a non-root user start the > vde_switch. I meant starting the vde_switch with root privileges (i.e. as tap0 interface) and allowing to connect to the socket for users who belongs to specific group (i.e. vde2-net for Debian system). I.e.: The global system interface is started as: iface tap0 inet static address 10.0.2.1 netmask 255.255.255.0 vde2-slirp -dhcp It means that the vde_switch is started as root user and vde2-net group (needed for kernel >2.6.18) and slirpvde is started as vde2-net user and vde2-net group. Just now it is possible to add some user to vde2-net group, i.e.: # adduser dexter vde2-net and the user can connect to the switch with his own application: dexter$ vdeq qemu -m 660 -net nic -net vde,sock=/var/run/vde2/tap0.ctl -boot c -hda Debian.img > > * Is it uploaded to experimental or sid? > > I think it's uploaded to Sid, but Guido is the Debian expert of this > group. :-) I don't know if this is the best solution for release times, > but I want to stress the fact that vde2 is *much* more stable than vde. > Lots of bugs have been fixed in the vde2 branch and not in vde 1.x. It is just ok, because vde2 is separate package and it will be held in sid, even if vde package will stay in etch. > > * Your package is splitted on 3 different binary packages. Why? I think > > the vde2 package should provide all files. > > We did this splitting for a good reason, or at least we think so. :-) > Let me try to explain: I think it is ok. Thanks for explanation. > > * New vde2 package doesn't provide upgrade path for users of old vde > > package. > > I suppose the only upgrade that may be needed is in your > /etc/network/interfaces part (but I'm not sure -- I haven't checked it > very well). vde2 aims to substitute vde in a quite painless way. The Some upgrade will be necessary only for /etc/network/interfaces file and vde-net user. I think it is not an issue just now. Please ignore the question :) > We'll take a look and, if you have no objections, we could try to merge > your additions to the main tree. Do you have specific advices or > anything? I hope you will accept my patches and /etc/network scripts :) > I explained you the reasons that pushed us towards the splitting and, if > you find them reasonable, we'd like to keep them in this way. Of course > we're open to suggestions. We'll notify the ftp-master. I see there is no need to modify the packages heavly, so I think there is no need to inform the ftp-master just now. He probably will ask if the VDE2 package was hijacked. I hope we can work together on VDE2 project so the situation would be clear. :) > Thank for your work. Sadly, we worked on the same thing for some time > and we didn't know of each other. I see no problem :) We have a slightly different experience and point of view. I would like to make the VDE2 as very good tool which fits to Debian standards (startup scripts, network configuration, non-root privileges suport, portability to other architectures and other OS-es). Greetings! -- .''`. Piotr Roszatycki : :' : mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
