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 attachment 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 attachment 39119 [details] openvpn-2.0_beta11.ebuild version bump openvpn-2.0_beta11.ebuild version bump
Created attachment 39121 [details, diff] 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 attachment 41114 [details] openvpn-2.0_beta11.ebuild 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.
Comment on attachment 41114 [details] openvpn-2.0_beta11.ebuild Fix dependancies in ebuild, change to virtual/os-headers instead of linux-headers
virtual/os-headers change works fine for me.
Created attachment 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 attachment 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 attachment 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 attachment 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 attachment 54926 [details] opepnvpn-2.0_rc19.ebuild New version for openvpn 2.0.
Created attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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!
OpenVPN 2.0 RELEASED http://openvpn.net/changelog.html
Created attachment 56581 [details, diff] 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 attachment 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 attachment 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 attachment 57178 [details, diff] 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
