Bugzilla Bug 50767

2004.05.09 -- OpenVPN 1.6.0 released (stable version) with Windows 2000/XP
support.
2004.05.09 -- OpenVPN 2.0_beta1 released.

http://openvpn.sourceforge.net/changelog.html

Created an attachment (id=31685) [details]
openvpn-2.0_beta2.ebuild

Almost identical to the 1.5.0 ebuild.  I'm unaware of any new dependencies and
whilst the pthreads flag is still present, it is currently unimplemented for
single-port-multi-client servers.  This should also lend itself quite well to
renaming for new versions...

The comment on the end of the .ebuild is that you need a
/etc/openvpn/*/ dir with local.conf, but I tried openvpn2 withou the ebuild
and using the init in the gentoo/ dir of the source file.

I needed to use files instead of directories

I had:

/etc/openvpn/home/local.conf
                 /local.up
            /work/local.conf
                 /local.up

Anfd I changed to:

/etc/openvpn/home.conf
            /home.up
            /work.conf
            /work.up

Hi!

I tested this thoroughly! Versions up to openvpn_2.0_beta5 just need bumps up in the file name. Working on x86. 

Up to beta3, it also works on amd64! beta4 and 5 clients produce this error when trying to connect to a beta5 server:

openvpn[28561]: EVENT: epoll_ctl EPOLL_CTL_MOD failed: Function not implemented (errno=38)
openvpn[28561]: Exiting


Thanks for your work so far!
Martin

Is this package orphaned?

I am actually concerned about both issues raised in this thread, and I'll
add another one, while I'm at it:

- Over a month after 1.6.0 is released, the respective ebuild is still missing
  from portage.

- ISTR that Gentoo tries to avoid changing upstream filesystem layout. With
  openvpn, though, Gentoo is the exception differing from upstream and, AFAICT,
  all other vendors: Gentoo requires an extra directory level under
  /etc/openvpn. I consider this a bug.

- The openvpn package is missing documentation files. Please include
  sample-config-files/, sample-keys/ and sample-scripts/verify-cn. Some
  of them _may_ be broken, but how are Gentoo users supposed to fix them
  and send patches upstream if for everything they know, those files
  don't even exist?

Just wanted to confirm that bumping the file name of the 1.5.0-r1 ebuild to
1.6.0 does work with no errors on two of my machines. Pthread support also
seems to work. I have not tested the 2.0 beta releases.

*** Bug 56221 has been marked as a duplicate of this bug. ***

ebuild for 1.6.0 should soon be released, this is getting old! :)

Created an attachment (id=39119) [details]
openvpn-2.0_beta11.ebuild version bump

openvpn-2.0_beta11.ebuild version bump

Created an attachment (id=39121) [details]
diff for files/openvpn

Using openvpn 2.0_beta11 you can chdir or chroot within local.conf. If you just
specify a relativ addressed config file (test/local.conf) openvpn can't respawn
and exits with error 'In [CMD-LINE]:1: Error opening configuration file:
test/local.conf: No such file or directory (errno=2)'. This diff adresses
local.conf with absolute path (/etc/openvpn/test/local.conf).

Apply this diff to files/openvpn

Just wanted to say that 2.0_beta11 with patch for /etc/init.d/openvpn works
very well here, and I'm looking forward to seeing it in portage.

I can confirm that openvpn-2.0_beta11.ebuild compiles cleanly. And so does
openvpn-1.6.0.ebuild, just bumbed directly from openvpn-1.5.0-r1.ebuild.

They seem to run fine too, but I haven't tested anything beside invoked the
binaries with different parameters.

Hi,

we are using the 2.0beta ebuilds for several months now. There are different clients (x86 and amd64) on Linux, all using this ebuild, connecting to a x86 Linux server. There have been no problems so far. The beta Windows client works well, too!

This should really get into the tree now..


Greetz,
Martin

Seems to work (2.0_beta11) so put this please in portage an mask it, if there
are any concerns.

Created an attachment (id=41114) [details]
Fix dependancies in ebuild, change to virtual/os-headers instead of
linux-headers

The previous ebuild breaks if you are using a 2.6 environment, since it depends
explicitly on the linux-headers - which is only usable for 2.4 headers.  I
changed the dependancy to virtual/os-headers. 

This dependancy seems silly, since glibc explicitly depends on os-headers,
wouldn't this, in theory, implicitly require the os-headers?   So some people
uninstall thier os-headers?  

Whatever the case, I do second the recommendation that this (version of the:)
ebuild be taken into portage.

(From update of attachment 41114 [details])
Fix dependancies in ebuild, change to virtual/os-headers instead of
linux-headers

virtual/os-headers change works fine for me.

Created an attachment (id=43241) [details]
openvpn 2.0 beta 15 ebuild

I hope, that besides untested ebuilds, which can always be seen in portage,
there will also be ebuilds, that work using betas, which work, too.
Or is this dependent on the payment of the submitter? :P

Created an attachment (id=43242) [details]
2.0_beta11.ebuild with "use doc" and gentoo/openvpn.init

I changed attachment#41114 [details] to
a) include all those samples and scripts if $USE includes doc and
b) use the gentoo init script provided by the openvpn tarball

I think the latter a good idea because
1) they better can keep their flags up to date
   (although there is a bug in the current one),
2) there need not be different versions of init scripts in the files dir and
3) the layout is compatible to other installations.

It builds, starts and stops OK.

I noticed that the /etc/init.d/openvpn-script isn't installed anymore with the
2.0_beta15 ebuild.
Maybe add it?

As of two days ago (2004-12-07), openvpn-2.0_rc1 was released.  Since it's now
left beta, would there be any chance of including this in the main portage
(keyword or even package masked)?

following version works on ppc and on x86:

OpenVPN 2.0_rc1 powerpc-unknown-linux [SSL] [LZO] built on Dec 11 2004

i just didn't install it by an ebuild...

i am looking forward to seeing this version in portage soon, because version 2 has some features i would see on my gentoo box like multi-vpn-connections...

FYI for those who save certificate passwords in a file to pass to OpenVPN:

2004.12.05 -- Version 2.0-beta20

* The ability to read --askpass and --auth-user-pass
  passwords from a file has been disabled by default.
  To re-enable, use ./configure --enable-password-save.

Created an attachment (id=47089) [details]
Ebuild for openvpn 2.0_rc6

Tested under MacOSX 10.3.7
Beta11 had problems with my tap devices under OS X....
Now no problem anymore.

There are ebuilds for OpenVPN 2.0 beta in Bug 80934, too.

We should combine the forces, and only maintain one bug with ebuild for OpenVPN 2.0.

Created an attachment (id=54382) [details]
ebuild for openvpn 2.0_rc17

*** Bug 80934 has been marked as a duplicate of this bug. ***

How about including the easy-rsa dir in /usr/share/openvpn, or somewhere else?
Maybe the files can be patched so that they generate keys in
/var/lib/openvpn-data or another dir? Just an idea...

Hmz, forget about the openvpn-data dir... Of course this stuff is all in
/etc/openvpn/someserver. Apologies for posting this too early ;-).

*** Bug 87388 has been marked as a duplicate of this bug. ***

Created an attachment (id=54926) [details]
opepnvpn-2.0_rc19.ebuild

New version for openvpn 2.0.

Created an attachment (id=54961) [details]
my own openvpn-2.0_rc19 ebuild

I submitted this as a new bug by accident, basing it directly on the 1.6
ebuild.  Thought I'd submit it here anyway, since it has more use flags and
possibly looks a little cleaner.  Also, you really want easy-rsa somewhere to
keep your sanity.

Created an attachment (id=54971) [details]
openvpn-2.0_rc19.ebuild

I updated the ebuild to include the work from Christian Roessner for installing
the easy-rsa scripts to /usr/share/openvpn/easy-rsa.  Thanks Christian, I
finally took the time to understand the ebuild a bit more and the work you did.

Do we really want easy-rsa in /usr/share/openvpn?  Users will have to copy it
out and modify it anyway to keep it from getting clobbered by an update and to
support more than one server, so it makes sense to make it a tarball in docs,
as an example.

According to http://openvpn.net/howto.html#pki, the easy-vpn scripts are
expected to be in /usr/share/openvpn/easy-vpn if the package was installed via
an RPM.  It is recommended they are copied else where before used.

Since the source tree does not exist after the compile, I thought it best to
copy the RPM location.

*** Bug 85774 has been marked as a duplicate of this bug. ***

Created an attachment (id=55670) [details]
openvpn-2.0_rc20.ebuild

Copied openvpn-2.0_rc19.ebuild to openvpn-2.0_rc20.ebuild to use the latest
version of openvpn.  Builds and installs the latest version.

Drop the comment off the end.  All versions of OpenVPN since 1.1.0 can be made
to talk to each other, however, some tweaking may be required.  This tweaking
is detailed at http://openvpn.net/compat.html

I submitted an alternative ebuild as an attachment here, which is now obsolete
and not too elegant, but which adds a few more use flags (six vs the two that
you've got) -- and I wasn't very thorough.  It includes easy_rsa as a tarball
in /usr/share/doc, which changes from upstream, but so does adding an extra
directory under /etc/openvpn.  If there's a concern about permissions, use file
permissions.  If there's a concern about scalability, have the alternative
Gentoo Way as an option, not a requirement.

Also, look at http://openvpn.net/changelog.html.  From that page:
2004.05.09 -- Version 1.6.0
2004.05.09 -- Version 2.0-beta1
2004.12.07 -- Version 2.0-rc1


That is, Versoin 1.6.0 was released ON THE SAME DAY as the first beta of
Version 2.0, yet it took Gentoo five months to get 1.6.0 in the tree, and 

According to the Gentoo changelog, the 1.6.0 ebuild was released on October
2nd, almost five months later.

The last modification to the 1.6.0 ebuild was February 5th, 2005.  Over two
months ago.  And 1.6 still is considered "unstable" by Gentoo people.

It's been nine months since the first Beta of 2.0, and four months since the
first Release Candidate, yet we still don't see one single ebuild, even an
unstable one, in the Portage tree.

Is there some reason this is being held back?  Because Debian Unstable has had
a version of 1.99 since November 2nd, 2004 -- that's five months.

As far as I'm concerned, at least SOME version of OpenVPN 2.0 is overdue by at
least 10 months.  Does this package need a maintainer?  There are 13 people
watching this bug.  I'm sure at least one of us would be competent and willing
to maintain such a simple package.

I, for one, am willing.

Created an attachment (id=56026) [details]
openvpn-2.0_rc21.ebuild

Ebuild update for rc21.  No changes to the file, only in the file name.  The
changes log from openvpn says the only change was:

Change license description from "GPL Version 2 or (at your option) any later
version" to just "GPL Version 2".

This ebuild doesn't create /etc/init.d/openvpn. Is that expected ?

That is seen only when installing openvpn 2.x from scratch, otherwise the /etc/init.d/openvpn file already exists.

Created an attachment (id=56116) [details]
openvpn-2.0_rc21.ebuild

Updated the ebuild to make sure that it installs the gentoo init script which
is part of the distribution.  Thanks to world.root@gmail.com for pointing out
the oversight.

Created an attachment (id=56559) [details]
Creates an empty /etc/openvpn dir, includes more docs, sed fix for upstream
init script

Funny, I was building this myself, when I saw that this bug had a new
attachment... I've added a sed fix to change the /usr/local to /usr in the
upstream-supplied Gentoo init script, incuded some more doc files, contribs,
etc.,  and create an empty /etc/openvpn dir for conf files.

We might want to add something to use the pam USE flag to install the auth-pam
plugins (which the current ebuild just ignores). Not sure where OpenVPN prefers
the "plugins" to go, though...

Created an attachment (id=56560) [details]
openvpn-2.0.ebuild

As I submitted my last ebuild, lo and behold, 2.0 (final) was released! I took
the opportunity to fix the SRC_URI by adding ${PV}. Have fun!

Hi,

I have modified the init script to load the /etc/openvpn/*/local.conf files... Why the actual scrit doesn't support this style of configuration? mah...

this is the addition to init function:

  done
  for c in `/bin/ls 2>/dev/null`; do
      if [ -d "$c" ]; then
              cd $c
              if [ -f "local.sh" ]; then
                  . local.sh
              fi
              rm -f $piddir/$c.pid
              $openvpn --daemon openvpn-$c --writepid $piddir/$c.pid --config
ork/$c/local.conf --cd $work/$c
              if [ $? = 0 ]; then
                  successes=1
              else
                  errors=1
              fi
              cd ..
      fi
  done

bye!

Hi,

I have modified the init script to load the /etc/openvpn/*/local.conf files... Why the actual scrit doesn't support this style of configuration? mah...

this is the addition to init function:

  done
  for c in `/bin/ls 2>/dev/null`; do
      if [ -d "$c" ]; then
              cd $c
              if [ -f "local.sh" ]; then
                  . local.sh
              fi
              rm -f $piddir/$c.pid
              $openvpn --daemon openvpn-$c --writepid $piddir/$c.pid --config
ork/$c/local.conf --cd $work/$c
              if [ $? = 0 ]; then
                  successes=1
              else
                  errors=1
              fi
              cd ..
      fi
  done

bye!

OpenVPN 2.0 RELEASED

http://openvpn.net/changelog.html

Created an attachment (id=56581) [details]
Fixes to /etc/init.d/openvpn

Is anybody else having problems with /etc/init.d/openvpn which comes with 2.0? 
I had to make a few simple changes to the file to get openvpn to work after
emerging version 2.0.  The changes are attached.

Created an attachment (id=56589) [details]
init.d script to support /etc/openvpn/*/*.conf configuration style

init.d script to support /etc/openvpn/*/*.conf configuration style

It searchs every /etc/openvpn/* subdirs and it executes openvpn with each
*.conf file contained.

OK, lets let the dust settle here, and give test reports for the ebuilds, so
they can be moved into Portage by a dev without worry about gotchas. Chime in,
folks!

*** Bug 89559 has been marked as a duplicate of this bug. ***

The necessary fixes like sed'ing the correct home of the binary makes sense,
but somehow the last ebuild seems like a
bloatware-documentation-monster-installation? 
Ever heard the term "manual"?

I don't see any reason in having the subdir-order, which 1.6.0 had. Keeping a
single file in a subdirectory does not make sense except you want to store your
keys in there. This can be a custom rule as everyone likes, but having a bundle
of directories does not make life better...

The rest seems ok.

De gustibus disputandum est...

I use subdirs with keys and other informations associated to the configuration file...

bye

Debian does this the Right Way.  Key files should always have different names,
and easy-rsa does this for you.  The keys are stored with strict permissions,
and the config files are named *.conf instead of */local.conf or */*.conf

There's absolutely no benefit for the casual user to having the subdirs.  The
ONLY benefit is for an installation large enough that the admin knows how to
change from defaults anyway.  There's no security benefit, because these are
all read by openvpn as root.

The only other benefit would be if OpenVPN did chroot or per-config uid's, but
neither of those makes sense, because the keys can still have the right
permissions, and the chroot can happen after keys/configs are read.

Qui Gon - I sure wish I knew which of the many ebuild versions that have been
submitted in the last day or so you were referring to. And what are you
referring to as "bloatware-documentation-monster-installation"? In my version,
there was mostly example configs and the easy-rsa scripts, not docs. Perhaps,
though, the ebuild should check the setting for the "doc" USE flag? Is that
what you want?

I agree with David regarding the subdirs. However, it appears that even Debian
doesn't do it the way that OpenVPN folks would want, since the OpenVPN folks
reccomend copying the /usr/share/doc/openvpn{version}/easy-rsa directory to
/etc/openvpn before customizing for your environment.

I have a test setup like so:

Client:
/etc/openvpn/client.conf
/etc/openvpn/secret.key

Server:
/etc/openvpn/server.conf
/etc/openvpn/secret.key

Why would you need more than this? If you had a client that connected to
multiple VPN'd networks, then they'd have multiple *.conf files. office.conf,
sister.conf, newyork.conf, etc.

However, I'm a new OpenVPN user, and I might not be seeing the bigger picture.

The bigger picture is, some installations might be huge, and most filesystems
(not all) are inefficient at huge directories of small files, and are much more
efficient when you break it up into subdirs.

But, this doesn't affect enough people to make it be the default, especially
considering that there's already a default that the OpenVPN people like.

No other ebuilds that I can think of check "doc" before installing manpages and
example configs.  If people really want, we can break easy-rsa into a separate
package, but I don't see the need.

On Debian, I copy the easy-rsa to /etc/openvpn/easy-rsa, so I don't pollute my
configs with it.  In the configs, I just reference files in easy-rsa/keys.  But
it doesn't make sense to have this on every machine, just on the server, unless
you're super-paranoid and actually use the CSRs.

That's why my old ebuild (for 2.0_rc19) tarred up the easy-rsa and put it in
doc -- if you're going to copy it anyway, why not install it as a tarball, and
just do something like:

cd /etc/openvpn; tar -xjpf /usr/doc/openvpn-2.0/easy-rsa.tar.bz2

My old ebuild (called "my own openvpn-2.0_rc19 ebuild") also had support for
twice to three times the use flags that the new openvpn-2.0.ebuild does. 
Things like socks5.  Absolutely no trouble at all to add (use_enable and tweak
deps), yet none of the other ebuilds here have that.  And tarring easy-rsa was
dirt-simple.

I don't mean to be overly territorial or anything, but why did my ebuild get
ignored?

I agree with David. It covers my idea!

The subdirectories make sense when using encrypted transmissions requiring keys, so your work-directory is not flooded by confs'n'keys.
Therefor a hierarchy for storing your files is certainly useful.
Nonetheless this location can be adjusted by parameters in the vpn-config besides other confs, that don't use keys and hence no subdirectories. Ergo subdirectories can be created manually and don't need any special treatment by adapting the old and ugly 1.6-structure.

As of chrooting I would certainly NOT use this globally spread configuration and 
create my own structure.

The same applies to a mass of profiles for use with openvpn as gentoo is not expected to make the work of professionals apply to average users as well.
And for sure, this 1.6-way simply does not.

Trying to create a convenience may also result in useless overhead.

Jesse, when briefly reviewing the last ebuild, that is meant to install the final release I was almost shocked how big the install-section for a simple daemon can be. What are you going to install? Sorry, this ebuild seems like installing the full newbie-starter-package and I don't share this way. The newbie-user will most likely review the openvpn-homepage for documentation as well as consult the manual (hint: man openvpn, yes, there is a manual). The sample-configurations are nice to have, but that's all anyway...

At least introduce the DOC-tag! Why does Gentoo have USE-Flags then??
I'm really shocked about the most recent evolution of ebuilds and the documents that are installed without ever being used again. You aren't using Windows, are you??

My philosophy covers applications and installations to be as original as possible, with as few modifications as possible. There are other Linux-Distributions out there that nearly have every aspect mutated and people wonder why they are so hard to administrate (one starts with S...).

Hey, I'm fine with whatever people want to do. My ebuild Works For Me(tm), and
there it sits in my portage overlay. No slight was meant, David - indeed your
e-build looks spiffy. I just didn't see it among the huge amount of noise on
this bug, and I just submitted an ebuild that I created that was mainly based
on the previous official portage release. So, I'll support your e-build as the
officai one, too, though I do belive that it would be nice to have it make use
of the "doc" USE flag.

Personally, I feel that drives are quite cheap these days, and I like to know
that, at my option, I can get sample configs and such (especially ones that are
as well doc'd as the OpenVPN ones) that are contemporaneous with the version of
the software I'm using installed and easily available for later use, without
the need for a net connection that might have just gone away, necessitating my
need for the docs to be local... But, that's part of what is great about Gentoo
- it should be a choice, not mandatory.

*** Bug 89629 has been marked as a duplicate of this bug. ***

Yes, being able to choose is very important and cheap harddrives is no valid
argument. I'm quite familiar with openvpn and personally I don't need any
documentation besides the manual for it. There is no need to let Gentoo become
a Windows-like dumpster for every damn useless file.
There should be a slim and easy installation for openvpn and more documentation
if needed. Not because "hardddrives are cheap". :rolleyes:

*** Bug 89645 has been marked as a duplicate of this bug. ***

It would be nice to have 2.0 in portage instead of gossip on usefulness of
examples and documentation. We have USE="doc" for that. *rolleyes*

Created an attachment (id=56656) [details]
openvpn-2.0-r1.ebuild using DOC

Jakub, I'm glad that you noticed that, too!! Really.
I'm stopping this insane discussion now by adding the ebuild myself, because it
seems that you like flaming without doing anything useful.
The sample-stuff is doc'ed now, and no one needs to install this.
Any complains? No? Thanks. :rolleyes:

guys... i tried the 2.0-r1 ebuild on ppc-macos and had problems with
config-format... then i compiled the sourcecode manually and succeded... first
version of openvpn didn't recognize the client-directive and ca-directive in my
config...

anyone else having this problems?

What's the exact error? Do you get an error-message at all or does it simply
"not work"?

Btw. why's openvpn not in portage yet? FreeBSD's Ports has already adopted it..
lol

Dunno but i'm tired of waiting. Good luck (removing myself from Cc:).

Qui Gon: 

Unrecognized keyword (2) client

then after commenting that out ca followed

the same config worked on my linux-installations and after compiling the original source, and installing it under /usr/local/sbin/ it worked... and asked me for a pem-password, like it was supposed todo.

*** Bug 90051 has been marked as a duplicate of this bug. ***

I need to roll out 2.0 on a good number of machines.
Does it look like this could get put into portage soon??
I don't want to rush anything, I am just wondering.

I've run it (2.0) on x86, amd64, and sparc without problems.
I've been field testing 2.0 ever since it first went beta, and I have never had any problems.

Nicolas:
Are you still having problems with the ebuild version?
If so which ebuild are you using?
I had an error like that once, I tried using a version compiled without the server / client mode. ( P2MP_SERVER bzw P2MP ifdefs )
Are you sure that was the exact wording of the error?

Nicolas - try out the openvpn-2.0.ebuild. It Works For Me(tm). If you have this
problem still, then the problem could be with the Gentoo-specific upstream
conf.

Created an attachment (id=57178) [details]
One patch to place vars in the correct place.

The archive vars is important for easy-rsa and it is being separate of the
tools.	This patch corrects this

*** Bug 90469 has been marked as a duplicate of this bug. ***

would a nice improvement to have openvpn2 in the tree. it's stable and i use it
on different machines. due to the lack of an "official" ebuild in the tree i'm
forced to maintain it one on every machine which is involved into the vpn in an
local overlay.

We need a bold developer to see this bug and make their move.

Warp Zero: Could you drop a comment? Jan sounds like he would care for this
piece, if you're under time constraints.

since warpzero seems to be inactive i'm going to take this over, as discussed
with carlo :)

ebuild for openvpn-2.0 now in the tree, thanks to everybody. the new ebuild
uses the examples useflag to let the user decide if he wants to have the
examples installed and uses the init script which comes with the distfile.
incvs