openvpn2: "Cannot allocate TUN/TAP dev dynamically"
Caspar Florian Ebeling
florian.ebeling at gmail.com
Thu Aug 28 08:58:05 PDT 2008
>> 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"
yeah you could probably hack it, but the guide is quite clear here:
A StartupItem is a MacPorts facility to run "daemons,"
a Unix term for programs that run continuously in the
background, rather than under the direct control of a user;"
I would not like to duplicate code either, obviously, but also not
violate things. It is true though, IIRC, that StartupItems are meant
to do more than managing daemons. But I don't know if MP startupitem
facilities have stricter assumptions. And this above sounds much
like it. Or the guide author was actually a bit too restrictive
in his description and nothing is wrong with your approach.
I don't know.
The only other port that mentions "kext" is macfuse,
according to rgrep. And that contains a Framework, and
I would imagine that places the kext into a well-known
place and takes care of everything. And least it has
no special means to start it.
> Another problem could be a conflict with an already installed Kext (maybe
> the legacy TUN/TAP driver or Tunnelblick).
MacPorts does not overwrite files but rather fails before doing so.
And then you just have to know how you manually configured your
system.
What is the "legacy TUN/TAP" btw?
Florian
--
Florian Ebeling
florian.ebeling at gmail.com
More information about the macports-dev
mailing list