openvpn2: "Cannot allocate TUN/TAP dev dynamically"

[Uwe Schwartz]

On Thu, Aug 28, 2008 at 1:51 PM, Caspar Florian Ebeling <
florian.ebeling at gmail.com> wrote:

> > I would also like to see TUN/TAP drivers in MacPorts.
> > After a quick look on the Makefile in the git repository the Portfile
> should
> > contain:
> >
> > use_configure    no
> > (because there is no configure)
> >
> > I'm not sure where to put the kext files. If we put it in the usual
> > /Library/Extensions folder we need:
> >
> > destroot.args    BASE=${destroot}
> > (the Makefile uses BASE instead of DESTDIR)
>
> I would think ${destroot}${prefix} might be even better,
> so that things end up in /opt/local/Library/Extensions.
> I tried it and loading/unloading seems to work nicely.
> So the location doesn't seem to matter if you load kexts
> explicitly.
>
> > This would cause a mtree violation. Thus we need:
> > destroot.violate_mtree    yes
> >
> > The next issues are the StartupItems. The Makefile provides an own way to
> > create the items, but we could also use MacPorts StartupItems.
>
> The problem with MacPorts StartupItems is that they look very
> server-centric to me, and we only need to trigger load and unload
> of the Kext. But that with su privileges. There is no pid to watch
> e.g.
>
> So one way of dealing with this would be to provide an oldfashioned
> script. But where to put that. I would be tempted to put it into
> /opt/local/init.d/,
> but there is nothing yet.


Well, I'm not an experienced Ports developer, so I don't know what's the
rigth way. But I don't like the idea to create a new method to start things.
A Script StartupItem would do the same. (5.7.3 in the guide). The
StartupItems from the original package provide already some scripts and the
PID issue could be solved by setting "startupitem.pidfile" to "none"


> Otherwise my Portfile is working. Maybe we just leave that part out for
> now and add a README.MacPorts, which explains:
>
> kextload KEXT_PATH # to load and get /dev/tap*
> kextunload KEXT_PATH # to unload and remove /dev/tap*
>
> > At the end I would suggest to not include the drivers in openvpn port,
> > because there are also other tools which use TUN/TAP.
>
> no, I agree, but there might be a dependency. Maybe only via a
> variant, but I think plain/full dependency would be arguable as well


Another problem could be a conflict with an already installed Kext (maybe
the legacy TUN/TAP driver or Tunnelblick).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080828/715c8d7f/attachment.html