Arch Linux

Hmm this seems ok to me - Thomas, Tobias, any issue with adding this?

So, whats about it?

The attached patch uses internal bash functionality to substitute -t with -d in tap_down. This way, we don't need to depend on sed anymore. It is also faster(pretty irrevelant, but true ;)).
This replaces initscripts_network_add_tun_tap_support2.patch.

Well, I guess I'll have to attach the patch when announcing it...

Ping for Thomas and Tobias. This patch looks good to me and I'd like to apply it - any issues with that?

The patch lacks an example for the conf.d file. It seems that one is supposed to specify all command line options for tunctl, and then replacing -t with -d should miraculously work for deleting it. I don't really like that, does it even work when you specify more than just the -t option (like -u)? I'd like to see an example configuration at least.

The example is in the uml_utilities patch in the initial bug report

Ah, didn't see it. Some things I don't like:

1) It doesn't abstract the tunctl stuff, but uses its exact syntax. We did this with ifconfig in rc.conf and are now unable to properly switch to /sbin/ip. We should rather have the possibility to specify a tap interface and a user who owns it and build the command ourselves.
2) If we do this, we should split tunctl from uml_utilities. In fact, uml_utilities is completely worthless (UML doesn't even work from what I see) and the only reason to install it is because you want tunctl. And people always try pacman -S tunctl, nobody even has the idea of looking into uml_utilities.

I mostly agree with Thomas' point - abstracting it a bit might be useful to "future proof" the feature.

Hum yes, sounds like a good idea. But how to implement?
We could parse one single string, or use different variables for storing the options. I think the last option is the better one.
Another thing is that hardcoding the user in the configuration is somewhat unclean. But what to do instead?
Well, one possibility could be to add a new group, lets just call it "tap", and assign all tap devices to that group by default. If one wishes to assign an individual tap interface to another user/group, he'll use seperate variables.

A sample configuration would look like this:
tap_tap1_user="foo_user"
tap_tap1_group="" #Optional, just for clarification
tap_tap2_user="" #Optional, just for clarification
tap_tap2_group="foo_group"
TAP_INTERFACES=(tap0 tap1 tap2)

Which would create 3 tap interfaces. Everyone in the "tap" group would have full access to tap0(the default setting). The user "foo_user" would have full access to tap1, and the group "foo_group" would have full access to tap2.
Thats easy to use, and can be extended without breaking something. Adding a tap0 interface will be just a
TAP_INTERFACES=(tap0)
for the most users.

Using this method, we could also easily add a new network interface configuration:
eth0_ip="192.168.0.123"
eth0_netmask="255.255.255.0"
eth0_broadcast="192.168.0.255"
eth2="eth2 192.168.0.124 netmask 255.255.255.0 broadcast 192.168.0.255"
INTERFACES=(eth0 eth1 eth2)

This would configure the 3 network interfaces eth0, eth1 and eth2. eth0 is manually configured, eth1 uses dhcp(default) and eth2 is configured using the old method. We can easily add new fields, and it allows us a smooth transition from the old network interface configuration scheme to the possibly new one. But well, thats another thing.

So I made an example implementation for the tun/tap stuff. Its divided into 3 parts:
uml_utilities_notuntap.patch:
Disables building of tunctl in extra/uml_utilities. Applies to the latest PKGBUILD from ABS.
tunctl.tar.gz:
A new package which just contains tunctl. It also adds the tun/tap configuration file in /etc/conf.d, and creates the "tap" group. Conflicts with old uml_utilities(which contains tunctl by itself).
initscripts_network_add_tun_tap_support4.patch:
Adds tun/tap functionality to the network initscript. Applies to the latest initscripts source from GIT.

I would like to see an automatic management of these tap interfaces too. Probably it's not relevant to others, but I totally agree with Thomas too, especially regarding the packaging.

Actually there is even a copy of this tunctl command in the vde package too, it's called vde_tunctl, but I would prefer a separate package, as Lisa did.

Will we see this released?

We are considering limiting the scope of the network initscript to not include this usecase. Is there any reason you cannot use netcfg instead?

unfortunately to set up a tun interface we also need the tunctl command which isn't installed by default nor provided by any package in core/extra/community

so, if we could provide a package for it and some "intelligence" into netcfg to manage a tun/tap interface, then using netcfg would be fine for me (I'd also expect to see the tunctl package set as dependency for netcfg)

if the suggestion is instead to use netcfg with some custom commands for the interface initialization and to install manually the tunctl command from an external source, then having netcfg installed would just force me to also install a bunch of other unneeded packages, the I won't use netcfg for it

@Giulio: if I understand correctly, we would need a new package to supply tunctl regardless of where tun/tap support is added, so getting someone to package that would be a first step.

I'm a bit hesitant to add this to initscripts, would it be possible to create a small "daemon" (script) that could be pakaged together with tunctl which would read a config file and set up / tear down the tuntap devices? Or is there a reason why this should be integrated with the initscripts/netcfg?

Thanks for replying Tom and please excuse me if my English is not so good :)

btw yes, having tunctl packaged would be a first step and I would be more than happy to maintain it if needed

a "daemon" bundled with the package that creates/deletes the tun/tap interfaces at startup would allow us to configure them via the standard INTERFACES parameter of rc.conf; that looks to me better than forcing the ysers to install netcfg

I would suggest making a separate /etc/tunctl.conf (I'm trying to limit the scope of rc.conf to make it easier to maintain), but the syntax could be the same as rc.conf if you wish. It might also be worth looking into what config files (if any) tunctl comes with out of the box?

1) tunctl is not needed (it is part of uml_utilities), you can manage tun/tap using iproute2's 'ip' tool:

* ip tuntap add dev $NAME mode tap user $USER
* ip tuntap del dev $NAME mode tap

$ ip tuntap help
Usage: ip tuntap { add | del } [ dev PHYS_DEV ]
[ mode { tun | tap } ] [ user USER ] [ group GROUP ]
[ one_queue ] [ pi ] [ vnet_hdr ]

Where: USER := { STRING | NUMBER }
GROUP := { STRING | NUMBER }

2) I hope I said this already, but this belongs in netcfg, not in initscripts.

@Thomas: thanks for the clarification. If tunctl is not needed, then adding this to netcfg is obviously the right solution. I will take the liberty of rephrasing the bug report to be against netcfg.

@Thomas I found this in a previous comment you posted:

1) It doesn't abstract the tunctl stuff, but uses its exact syntax. We did this with ifconfig in rc.conf and are now unable to properly switch to /sbin/ip. We should rather have the possibility to specify a tap interface and a user who owns it and build the command ourselves.
2) If we do this, we should split tunctl from uml_utilities. In fact, uml_utilities is completely worthless (UML doesn't even work from what I see) and the only reason to install it is because you want tunctl. And people always try pacman -S tunctl, nobody even has the idea of looking into uml_utilities.

Like you, I'd like to see rc.conf to switch from ifconfig to ip and, if I understand correctly, you would prefer to manage the tap interfaces with 'ip' too, instead of having a special "tunctl" package.

We could then manage the tap interfaces from rc.conf, without having to install netcfg.

So, would it be via a special "tunctl" package or via the standard "iproute2" package, I think that the management of tap interfaces should be left against the initscripts, not netcfg.

Everything should be done by iproute2 (one day). However, initscripts should do as little as possible (the purpose of initscripts is to boot the computer not to deal with networking), so anything that is not strictly speaking necessary to get your computer up and running should not be in initscripts but in netcfg.

In conclusion: tun/tap should be handled by netcfg.

It would not be difficult to create a dedicated module in netcfg: but what would be the purpose of that? What configuration do you want? What's the point of creating tuntap interfaces without using them?

@Rémy: I looked into this, but then promptly forgot. I think the point is that a regular user does not have the permissions to create tun/tap interfaces, but they might have the permissions to use them.

Maybe someone who knows better could clarify?

A basic interface has been added in netcfg to create the tun/tap interfaces, but of course with no route configuration.

Remy the tap interface should most probably be configured with an IP or some static routes to be useful. I was expecting something similar to what you did for VLANs.

Pleae explain what it means for a tun/tap interface to have an IP address when it's not connected to a program. As far as I know, it's not possible to do anything like this. Or, please tell me what commands you use to set an IP address on a freshly created tap interface.

I'm not sure I've understood what you're asking for.

I do set the ip address on a tap interface using the standard ifconfig/ip commands and after it's created I plug it into a VDE switch where also a number of QEMU network interfaces are plugged.

One of the reasons why I do this is that VDE can build a virtual switch across different physical hosts; this provides me the capability of spawning a VM on different hosts having it always connected to the same virtual network.