Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-15 Thread Alon Bar-Lev
On Tue, May 15, 2012 at 10:34 AM, Seth Mos  wrote:
> Op 13-5-2012 20:23, Alon Bar-Lev schreef:
>> On Sun, May 13, 2012 at 9:10 PM, Gert Doering  wrote:
>
>> Come on! most of installations are plain public key without any of
>> these plugins.
>> There is no need for these if you configure your server.
>> I simply don't understand your attitude... sorry, I simply don't.
>
> Please note that we include OpenVPN in the pfSense product, and we
> pretty much provide access to a huge number of options in the UI.
>
> There are quite a lot of installs out there that use OpenVPN with
> certificates and Radius authentication.
>
> Regardless, we need to ship with pretty much all options enabled. We are
> not going to ship 15 images to get all the options. And letting users
> install other "packages" to get the features seems silly.
>
> We're not a OpenWRT where the small memory footprint is limiting what
> you can do.
>
> So just because most users don't use the other features that makes it a
> valid argument? Ehm. not sure on that.
>
> Cheers,
>
> Seth

So basically what you want is to use adding the auth radius into the
core package.

Alon.



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-15 Thread Seth Mos

Op 13-5-2012 20:23, Alon Bar-Lev schreef:

On Sun, May 13, 2012 at 9:10 PM, Gert Doering  wrote:



Come on! most of installations are plain public key without any of
these plugins.
There is no need for these if you configure your server.
I simply don't understand your attitude... sorry, I simply don't.


Please note that we include OpenVPN in the pfSense product, and we 
pretty much provide access to a huge number of options in the UI.


There are quite a lot of installs out there that use OpenVPN with 
certificates and Radius authentication.


Regardless, we need to ship with pretty much all options enabled. We are 
not going to ship 15 images to get all the options. And letting users 
install other "packages" to get the features seems silly.


We're not a OpenWRT where the small memory footprint is limiting what 
you can do.


So just because most users don't use the other features that makes it a 
valid argument? Ehm. not sure on that.


Cheers,

Seth



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-15 Thread Samuli Seppänen

> My two cents on this is as follows:
>
> As a package maintainer, I think this is going to prove to be a lot of work.  
> It means there are more packages to maintain, over the one I need to now.  
> HOWEVER, from the OpenVPN development process, I think it's best to split 
Yes, unless we can move the plugin packaging tasks to other people. That
would be easier with separated plugins, but still a big "if". Perhaps I
should ask if somebody's willing to take over this challenge...

Samuli



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories - Discussion Summary

2012-05-14 Thread David Sommerseth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/05/12 20:31, Alon Bar-Lev wrote:
>>> And this is the last thing I'm going to say in this
>>> discussion.
> 
> This is not the way to do discussion. So what now... you decide you
> enforce? as you are the only one that can commit?

No, I am not enforcing anything.  I'm pulling myself out of this
discussion.  And as there is no patch here, just an RFC, there is
nothing to apply or commit.

I think the majority of the discussion has been repeating itself, the
later replies have not been a fruitful discussion at all and has not
provided any new discussion points which really changes the
situation/opinions.

And I am really not happy about the tone some of the replies have
taken.  It feels like there is some disrespect to others opinions than
respect.

Considering that you sent an RFC, the majority of the replies have
been more in favour of not doing a split vs doing the split; And you
have received comments to your request.

Fair enough, you are allowed to discuss and argue for you point of
view - and I don't want to restrict your freedom here.  But the bottom
line is: it has not moved the opinion of anyone.

All in all, I see no reason to continue participating in this
discussion from my side - it is just becoming more like a traditional
flame war instead of a insightful discussion.

My comment was to make it clearly that I will not pay attention to
this discussion any more.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+w+PIACgkQDC186MBRfroRLgCfR5Q8b46szCyajDgepMvATqxu
5pQAoJR08HU6dFYanCut3wNQiTH4P2Cf
=QlmV
-END PGP SIGNATURE-



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Gert Doering
Hi,

On Sun, May 13, 2012 at 09:23:04PM +0300, Alon Bar-Lev wrote:
> > Huh?  You're the master of Autoconf, and I'm sure you will be able to
> > produce a working PAM detection for those platforms that have it.
> 
> Yes, and as such I tell you that automatic detection is something that
> leads to package breakage.
> We already discussed that in the lzo subject.

We're not talking about extra libraries that might or might not be there -
on all systems I named, PAM is part of the basic operating system, as
is "libc" or one of the zillion header files that you're currently testing
for.

> I know you are fundamentally against any change, but I think I proved
> very well that I actually know what I am doing.

Now you are the one who is opposing change.  You asked what we want, and
if the plugins should not be split, how the build system should be adapted.

This is what I answered: if we want to adapt the build system for the
plugins, compile them by default, and install them.  And now you're finding
reasons why this is bad.

Fine, leave it at that - there's quite obviously not much support for the
split, and since you do not want to compile & install by default, nobody
can force you to implement that.


> >> >> These plugins should be optional I don't see any value in enforcing
> >> >> them and their dependencies.
> >> >
> >> > If these plugins are useful for a large number of users, there is no
> >> > point in not installing them by default.
> >>
> >> They are not.
> >
> > Unfounded claim.
> 
> I know one or two installations, and I am tracking this project more
> than 6 years.
> Come on! most of installations are plain public key without any of
> these plugins.

All our corporate servers *do* use auth-pam.  Which is crucial if you
want to do things like OTP passwords that are handled by PAM - many
vendor solutions provide PAM modules, and it's quite nice to be able
to use those without any extra hoops.

For the record, these servers user FreeBSD with the default port, which
*does* install both plugins, and I find that tremendously useful.

ovsrv1$ pkg_info -W /usr/local/lib/openvpn-auth-pam.so
/usr/local/lib/openvpn-auth-pam.so was installed by package openvpn-devel-201034


> There is no need for these if you configure your server.

How do you know what I need for my servers?  I *do* need them for my
server, and I'm very happy that the FreeBSD port saves me from having
to worry about the plugins manually every time I install a new OpenVPN
version.

> I simply don't understand your attitude... sorry, I simply don't.

My attitude is very simple.  I'm a sysadmin and network admin, do IPv6 
deployments, and regularily have to fight open source software that comes
with non-useful defaults.

Everything that creates extra work for sysadmins is bad.

Everything that brings in religion and delays software releases for 
"purity" reasons, while people are waiting for features to be delivered
(and have to live with patched packages, instead of using upstream sources
directly) is bad.

Too-complex software is *bad*.  Stuff that looks nice while in computer
science class, but that will bring in more complex failure modes - because
that will inevitably one day bite an overworked sysadmin, and they do not
like that.


> >> BTW: Packager of what platform are you?
> >
> > openwrt.  Not that this is of any relevance.
> 
> Exactly, so I think I am more experienced distro maintainer, 

Which OpenVPN package are you maintaining, please remind me again?

(I am also going to win any dick size war, of course, but that's also
non relevant as I'm already married)

> please
> understand that I am taking from first hand experience, and I would
> like to help, plain positive help... I really don't understand why you
> are trying to force your opinion if you have theoretical knowledge.

*cough*

> BTW: openwrt is a good example of a platform that does not need these
> plugins right?

Indeed.  So, yes, you have won.  Don't enable them in the build system.

Remind me again why I am bothering?

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpAGvWYQ1pJq.pgp
Description: PGP signature


Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Fabian Knittel
Hi Alon,

2012/5/13 Alon Bar-Lev :
> On Sun, May 13, 2012 at 9:10 PM, Gert Doering  wrote:
>> Huh?  You're the master of Autoconf, and I'm sure you will be able to
>> produce a working PAM detection for those platforms that have it.
>
> Yes, and as such I tell you that automatic detection is something that
> leads to package breakage.

How does PAM detection relate to the question whether to split out the
plugin? Wouldn't the plugin's configure also need to detect PAM? As
already discussed previously, I much prefer configure to notice a
missing development package than to run into a failing "make" run.

And why would automatic pam detection lead to package breakage? Have
an option for enabling / disabling plugins. If a plugin is enabled and
needs PAM, check for the existence of PAM. If PAM isn't found, exit
configure and tell the user to pass the proper paths for pam headers
and libraries.

>>> >> These plugins should be optional I don't see any value in enforcing
>>> >> them and their dependencies.
>>> >
>>> > If these plugins are useful for a large number of users, there is no
>>> > point in not installing them by default.
>>>
>>> They are not.
>>
>> Unfounded claim.
>
> I know one or two installations, and I am tracking this project more
> than 6 years.
> Come on! most of installations are plain public key without any of
> these plugins.
> There is no need for these if you configure your server.
> I simply don't understand your attitude... sorry, I simply don't.

As already mentioned elsewhere in this thread, the currently included
plugins aren't a huge burden to maintain. So even if we were to agree
that most people don't need them by default, I would suggest to change
the build default, not throw them out of the repository.

I can see where the purity of the split-out would appeal to you, but
the increased number of separate repositories, releases, packages,
etc. to maintain forms a strong counter-point in my opinion. So I'm
against splitting out the plugins for now. (Just saw Eric's
openvpn-contrib proposal. Might serve as a compromise, but then we'd
still lose the purity advantage ...)

Cheers
Fabian



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Eric Crist
David,

You misrepresent my opinion.  I do NOT want a split, but will deal with one (as 
a packager) if it becomes necessary.  I would much prefer there to never be a 
split, and for everything to be handled with configure args or ifdefs in the 
make file.

-
Eric F Crist



On May 13, 2012, at 15:42:10, Eric Crist wrote:

> What I had mentioned might be a good alternative in IRC was to have an 
> openvpn package, and an openvpn-contrib.  Two isn't hard, 17 or 500 is.  
> This, still, didn't seem to be liked by Alon (not calling you out, per se, 
> but stating fact).
> 
> Not sure where we should go from here other than to stay where we are.  No 
> point in moving until we're all ready to move in the same direction.  If need 
> be, we can enforce a dev-team sack race when we next get together. ;)
> 
> -
> Eric F Crist
> 
> 
> 
> On May 13, 2012, at 07:40:07, Seth Mos wrote:
> 
>> Chiming in here,
>> 
>> Although pfSense is basically a giant tarbal, it has the benefit of being 
>> sure that all parts of it fit together. We also have installable packages 
>> and we frequently see issues with that. We are trying to solve some of them 
>> using PBI packages just so that each "package" always has it's dependencies 
>> in check.
>> 
>> Although we are just a "consumer", we'd rather have a single FreeBSD port 
>> that we build then 5 ports we need to update, with all the required 
>> dependencies.
>> 
>> Our github repo is split into one for packages, tools and pfSense. But each 
>> is really a standalone thing, because there is no overlap. Which probably my 
>> point, the plugin is useless without the main.
>> 
>> The one git repo for pfSense is pretty manageable, even more so through git 
>> with Pull requests. The single biggest jump in commits and patches from the 
>> community is moving to GitHub. It makes contributions so much easier. That 
>> said, even for us the amount of simultaneous active coders is about 5, 
>> although we do see small patches and pull requests from about 30 or so 
>> people a year.
>> 
>> I see nagios using nagios-plugins, that has seperate releases from the main 
>> nagios. So there's that too.
>> 
>> Just a few thoughts from the other end.
>> 
>> Really, really, _really_ looking forward to Viscosity and Tunnelblick 
>> shipping Ipv6 enabled clients. Pretty please.
>> 
>> Cheers,
>> 
>> Seth
>> pfSense developer
>> 
>> Op 13 mei 2012, om 13:12 heeft Gert Doering het volgende geschreven:
>> 
>>> Hi,
>>> 
>>> On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote:
>> Can't we progress?
> 
> Why is that progress?
> 
> Change always has drawbacks.  If the plus sides outweighs the drawbacks,
> change is good.  Change for change's sake, "just because you can change
> it", is not.
 
 Yes, but still from your responses I don't see any drawback... maybe I
 am slow learner...
>>> 
>>> Drawback to maintainers and sysadmins has already been mentioned by
>>> ecrist and me.  Try being a sysadmin for a few weeks and figure out
>>> which bits of xorg you need to download to install xinit, assuming
>>> you have a system without any X libraries and headers yet (in the xorg
>>> example: splitting off "xinit" might actually make sense, but splitting
>>> the basic infrastructure to build anything into about 50 different
>>> "xyz-library" and "xyz-headers" packages is crazyness).
>>> 
>>> But the onus is not particularily on me: you have not put forward 
>>> convincing arguments why splitting off a very small number of files 
>>> that only make use in the context of OpenVPN into their own repository 
>>> has any *advantage*.
>>> 
>>> The handwavy argument "it will attract more users!" can be countered by
>>> similarily handwaving "I, as a user, hate to download multiple packages
>>> to figure out how to start contributing, and so it will scare *away*
>>> users".
>>> 
>>> 
>>> As a counterexample, look at Apache.  They have heaps of modules in
>>> the main tarball, and have no issues with frequent release and with
>>> attracting developers.  And still, modules maintained by non-apache
>>> developers can be developed externally, without having to splitt off
>>> all existing modules beforehand.
>>> 
>>> gert
>>> -- 
>>> USENET is *not* the non-clickable part of WWW!
>>> //www.muc.de/~gert/
>>> Gert Doering - Munich, Germany 
>>> g...@greenie.muc.de
>>> fax: +49-89-35655025
>>> g...@net.informatik.tu-muenchen.de
>>> --
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and 
>>> threat landscape has changed and how IT managers can respond. Discussions 
>>> will include endpoint security, mobile security and the latest in malware 
>>> threats. 
>>> 

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Eric Crist
What I had mentioned might be a good alternative in IRC was to have an openvpn 
package, and an openvpn-contrib.  Two isn't hard, 17 or 500 is.  This, still, 
didn't seem to be liked by Alon (not calling you out, per se, but stating fact).

Not sure where we should go from here other than to stay where we are.  No 
point in moving until we're all ready to move in the same direction.  If need 
be, we can enforce a dev-team sack race when we next get together. ;)

-
Eric F Crist



On May 13, 2012, at 07:40:07, Seth Mos wrote:

> Chiming in here,
> 
> Although pfSense is basically a giant tarbal, it has the benefit of being 
> sure that all parts of it fit together. We also have installable packages and 
> we frequently see issues with that. We are trying to solve some of them using 
> PBI packages just so that each "package" always has it's dependencies in 
> check.
> 
> Although we are just a "consumer", we'd rather have a single FreeBSD port 
> that we build then 5 ports we need to update, with all the required 
> dependencies.
> 
> Our github repo is split into one for packages, tools and pfSense. But each 
> is really a standalone thing, because there is no overlap. Which probably my 
> point, the plugin is useless without the main.
> 
> The one git repo for pfSense is pretty manageable, even more so through git 
> with Pull requests. The single biggest jump in commits and patches from the 
> community is moving to GitHub. It makes contributions so much easier. That 
> said, even for us the amount of simultaneous active coders is about 5, 
> although we do see small patches and pull requests from about 30 or so people 
> a year.
> 
> I see nagios using nagios-plugins, that has seperate releases from the main 
> nagios. So there's that too.
> 
> Just a few thoughts from the other end.
> 
> Really, really, _really_ looking forward to Viscosity and Tunnelblick 
> shipping Ipv6 enabled clients. Pretty please.
> 
> Cheers,
> 
> Seth
> pfSense developer
> 
> Op 13 mei 2012, om 13:12 heeft Gert Doering het volgende geschreven:
> 
>> Hi,
>> 
>> On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote:
> Can't we progress?
 
 Why is that progress?
 
 Change always has drawbacks.  If the plus sides outweighs the drawbacks,
 change is good.  Change for change's sake, "just because you can change
 it", is not.
>>> 
>>> Yes, but still from your responses I don't see any drawback... maybe I
>>> am slow learner...
>> 
>> Drawback to maintainers and sysadmins has already been mentioned by
>> ecrist and me.  Try being a sysadmin for a few weeks and figure out
>> which bits of xorg you need to download to install xinit, assuming
>> you have a system without any X libraries and headers yet (in the xorg
>> example: splitting off "xinit" might actually make sense, but splitting
>> the basic infrastructure to build anything into about 50 different
>> "xyz-library" and "xyz-headers" packages is crazyness).
>> 
>> But the onus is not particularily on me: you have not put forward 
>> convincing arguments why splitting off a very small number of files 
>> that only make use in the context of OpenVPN into their own repository 
>> has any *advantage*.
>> 
>> The handwavy argument "it will attract more users!" can be countered by
>> similarily handwaving "I, as a user, hate to download multiple packages
>> to figure out how to start contributing, and so it will scare *away*
>> users".
>> 
>> 
>> As a counterexample, look at Apache.  They have heaps of modules in
>> the main tarball, and have no issues with frequent release and with
>> attracting developers.  And still, modules maintained by non-apache
>> developers can be developed externally, without having to splitt off
>> all existing modules beforehand.
>> 
>> gert
>> -- 
>> USENET is *not* the non-clickable part of WWW!
>>  //www.muc.de/~gert/
>> Gert Doering - Munich, Germany 
>> g...@greenie.muc.de
>> fax: +49-89-35655025
>> g...@net.informatik.tu-muenchen.de
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. 
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint 

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories - Discussion Summary

2012-05-13 Thread Alon Bar-Lev
On Sun, May 13, 2012 at 9:11 PM, David Sommerseth
 wrote:
> So, please!  Can we rather spend our precious time and energy to fix
> *real* bugs?   

I would like to spend time in completing the order of build/packaging,
a task I started and would like to end, giving all my experience at
that subject, which is quite large.

BTW: krzee (user) at IRC also in favor of split, I also contacted
debian and rpmforge openvpn package maintainer for their views on this
matter.

Except of Eric, nobody is distro maintainer, and after short talk to
Eric, he does not realize that 3.0 is not going to happen any time
soon.

> And this is the last thing I'm going to say in this discussion.

This is not the way to do discussion.
So what now... you decide you enforce? as you are the only one that can commit?

Alon.



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Alon Bar-Lev
On Sun, May 13, 2012 at 9:10 PM, Gert Doering  wrote:
> Hi,
>
> On Sun, May 13, 2012 at 04:10:54PM +0300, Alon Bar-Lev wrote:
>> >> And always have pam dependency for this example?
>> >
>> > FreeBSD, NetBSD, all Linuxes and Solaris have PAM anyway.
>> >
>> > So make this "if pam libraries + headers are detected, install auth-pam,
>> > otherwise, not".
>>
>> We already discussed the automatic detection and integrity failure as result.
>
> Huh?  You're the master of Autoconf, and I'm sure you will be able to
> produce a working PAM detection for those platforms that have it.

Yes, and as such I tell you that automatic detection is something that
leads to package breakage.
We already discussed that in the lzo subject.
I know you are fundamentally against any change, but I think I proved
very well that I actually know what I am doing.

>
>> >> These plugins should be optional I don't see any value in enforcing
>> >> them and their dependencies.
>> >
>> > If these plugins are useful for a large number of users, there is no
>> > point in not installing them by default.
>>
>> They are not.
>
> Unfounded claim.

I know one or two installations, and I am tracking this project more
than 6 years.
Come on! most of installations are plain public key without any of
these plugins.
There is no need for these if you configure your server.
I simply don't understand your attitude... sorry, I simply don't.

>> Exactly because the are not useful, I am for the split.
>> Anyway, if you follow the apache example there is explicit
>> enable/disable to each.
>
> And there are some that are enabled by default.  Your point?

These which enabled by default requires for proper apache functionality.
There are absolutely no openvpn plugin that is actually required for anything.
Please stop trying to just try to oppose... but think of the relevant
of what you are referring.
First you compare xorg to openvpn, which is totally invalid.
Then you compare openvpn to apache, which is also invalid.
What next?

>> BTW: Packager of what platform are you?
>
> openwrt.  Not that this is of any relevance.

Exactly, so I think I am more experienced distro maintainer, please
understand that I am taking from first hand experience, and I would
like to help, plain positive help... I really don't understand why you
are trying to force your opinion if you have theoretical knowledge.

BTW: openwrt is a good example of a platform that does not need these
plugins right?

Alon.

>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>                                                           //www.muc.de/~gert/
> Gert Doering - Munich, Germany                             g...@greenie.muc.de
> fax: +49-89-35655025                        g...@net.informatik.tu-muenchen.de



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Gert Doering
Hi,

On Sun, May 13, 2012 at 04:10:54PM +0300, Alon Bar-Lev wrote:
> >> And always have pam dependency for this example?
> >
> > FreeBSD, NetBSD, all Linuxes and Solaris have PAM anyway.
> >
> > So make this "if pam libraries + headers are detected, install auth-pam,
> > otherwise, not".
> 
> We already discussed the automatic detection and integrity failure as result.

Huh?  You're the master of Autoconf, and I'm sure you will be able to
produce a working PAM detection for those platforms that have it.

> >> These plugins should be optional I don't see any value in enforcing
> >> them and their dependencies.
> >
> > If these plugins are useful for a large number of users, there is no
> > point in not installing them by default.
> 
> They are not.

Unfounded claim.

> Exactly because the are not useful, I am for the split.
> Anyway, if you follow the apache example there is explicit
> enable/disable to each.

And there are some that are enabled by default.  Your point?

> BTW: Packager of what platform are you?

openwrt.  Not that this is of any relevance.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpvmW85gTbbh.pgp
Description: PGP signature


Re: [Openvpn-devel] [RFC] Split plugins into their own repositories - Discussion Summary

2012-05-13 Thread David Sommerseth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/05/12 18:55, Alon Bar-Lev wrote:
> Hello,
> 
> Now, I also have the courage to ask one more question regarding 
> build
> 
> We currently have: - auth-pam - defer - down-root - examples

I'm just giving a summary here of the discussion, how I see the
discussion.  And hope we can close this one soon.  The thread is
long and many of the arguments are repeated several times.

Basically, the situation is as now:

Those who opposes a split now are Adriaan, Gert and I, which are all
active with development in the tree.  Seth has also voted against.
And Eric says "not before v3.0".

Those in favour are Alon, Samuli and Eric after v3.0.

- --

Then let's look at the commit history for these plug-ins which are
discussed.  The git log goes back to the old BETA21 SVN branch.

auth-pam/auth-pam.c   - 17 changes
auth-pam/pamdl.c  -  7 changes
auth-pam/pamdl.h  -  6 changes
down-root/down-root.c - 12 changes

That is the total number of changes to each of these files since
September 26, 2005.

Further, all *nix platforms have the concept of root users and can do
seteuid() stuff (which makes down-root useful) and all uses PAM as
recommended default (which makes auth-pam useful)

- ---

So to summarize it, how I see it:

* There is resistance to such a split
* These modules are generally useful on all *nix platforms
* They are not requiring a lot of extra maintenance at all currently
* Current inclusion in main tree makes package maintainers more happy

When the maintenance burden of having these *two* plug-ins in the main
tree gets so big it affects the core openvpn development and release
cycles - that's the time it is appropriate to consider a split.

So, please!  Can we rather spend our precious time and energy to fix
*real* bugs?   

And this is the last thing I'm going to say in this discussion.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+v+T0ACgkQDC186MBRfrp5TACfeIKA5P2GBfKVO031KnXpmo2W
UEkAoJEsZEgN7y5z9qcPjHa1/C3U5i6b
=1/kX
-END PGP SIGNATURE-



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Alon Bar-Lev
On Sun, May 13, 2012 at 4:07 PM, Gert Doering  wrote:
> Hi,
>
> On Sun, May 13, 2012 at 03:24:59PM +0300, Alon Bar-Lev wrote:
>> > If we ignore the examples, we really only have "auth-pam" and "down-root"
>> > in the main distribution today, and those are useful in many cases - so
>> > I'd go for "always build and install them".
>>
>> And always have pam dependency for this example?
>
> FreeBSD, NetBSD, all Linuxes and Solaris have PAM anyway.
>
> So make this "if pam libraries + headers are detected, install auth-pam,
> otherwise, not".

We already discussed the automatic detection and integrity failure as result.

>
>> These plugins should be optional I don't see any value in enforcing
>> them and their dependencies.
>
> If these plugins are useful for a large number of users, there is no
> point in not installing them by default.

They are not.
Exactly because the are not useful, I am for the split.
Anyway, if you follow the apache example there is explicit
enable/disable to each.

BTW: Packager of what platform are you?

Alon.



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Alon Bar-Lev
On Sun, May 13, 2012 at 3:19 PM, Gert Doering  wrote:
> Hi,
>
> On Sun, May 13, 2012 at 02:26:05PM +0300, Alon Bar-Lev wrote:
>> OK... now you are talking... so you say that like apache we need to
>> integrate the plugins to main build system, this was the other
>> alternative.
>
> This would make more sense to me.  Either have them as optional
> "configure" components, or just build and install all of them all
> the time.
>
> If we ignore the examples, we really only have "auth-pam" and "down-root"
> in the main distribution today, and those are useful in many cases - so
> I'd go for "always build and install them".

And always have pam dependency for this example?
These plugins should be optional I don't see any value in enforcing
them and their dependencies.

Alon.



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Alon Bar-Lev
Hello Seth,

Thank you this is interesting.

I don't know pfSense... do you have the nation of plugin which is
independent from the core?
I mean pre-defined interface, which is backward compatible?
I looked briefly on the source tree and did not find my way...

A counter example of nagios is cacti... which provides plugins as
their own... :)

So basically you think that openvpn or openvpn-plugin package should
install all plugins, and depend on the union of all, right?

Alon.

On Sun, May 13, 2012 at 2:40 PM, Seth Mos  wrote:
> Chiming in here,
>
> Although pfSense is basically a giant tarbal, it has the benefit of being 
> sure that all parts of it fit together. We also have installable packages and 
> we frequently see issues with that. We are trying to solve some of them using 
> PBI packages just so that each "package" always has it's dependencies in 
> check.
>
> Although we are just a "consumer", we'd rather have a single FreeBSD port 
> that we build then 5 ports we need to update, with all the required 
> dependencies.
>
> Our github repo is split into one for packages, tools and pfSense. But each 
> is really a standalone thing, because there is no overlap. Which probably my 
> point, the plugin is useless without the main.
>
> The one git repo for pfSense is pretty manageable, even more so through git 
> with Pull requests. The single biggest jump in commits and patches from the 
> community is moving to GitHub. It makes contributions so much easier. That 
> said, even for us the amount of simultaneous active coders is about 5, 
> although we do see small patches and pull requests from about 30 or so people 
> a year.
>
> I see nagios using nagios-plugins, that has seperate releases from the main 
> nagios. So there's that too.
>
> Just a few thoughts from the other end.
>
> Really, really, _really_ looking forward to Viscosity and Tunnelblick 
> shipping Ipv6 enabled clients. Pretty please.
>
> Cheers,
>
> Seth
> pfSense developer
>
> Op 13 mei 2012, om 13:12 heeft Gert Doering het volgende geschreven:
>
>> Hi,
>>
>> On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote:
> Can't we progress?

 Why is that progress?

 Change always has drawbacks.  If the plus sides outweighs the drawbacks,
 change is good.  Change for change's sake, "just because you can change
 it", is not.
>>>
>>> Yes, but still from your responses I don't see any drawback... maybe I
>>> am slow learner...
>>
>> Drawback to maintainers and sysadmins has already been mentioned by
>> ecrist and me.  Try being a sysadmin for a few weeks and figure out
>> which bits of xorg you need to download to install xinit, assuming
>> you have a system without any X libraries and headers yet (in the xorg
>> example: splitting off "xinit" might actually make sense, but splitting
>> the basic infrastructure to build anything into about 50 different
>> "xyz-library" and "xyz-headers" packages is crazyness).
>>
>> But the onus is not particularily on me: you have not put forward
>> convincing arguments why splitting off a very small number of files
>> that only make use in the context of OpenVPN into their own repository
>> has any *advantage*.
>>
>> The handwavy argument "it will attract more users!" can be countered by
>> similarily handwaving "I, as a user, hate to download multiple packages
>> to figure out how to start contributing, and so it will scare *away*
>> users".
>>
>>
>> As a counterexample, look at Apache.  They have heaps of modules in
>> the main tarball, and have no issues with frequent release and with
>> attracting developers.  And still, modules maintained by non-apache
>> developers can be developed externally, without having to splitt off
>> all existing modules beforehand.
>>
>> gert
>> --
>> USENET is *not* the non-clickable part of WWW!
>>                                                           //www.muc.de/~gert/
>> Gert Doering - Munich, Germany                             
>> g...@greenie.muc.de
>> fax: +49-89-35655025                        
>> g...@net.informatik.tu-muenchen.de
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. 
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Seth Mos
Chiming in here,

Although pfSense is basically a giant tarbal, it has the benefit of being sure 
that all parts of it fit together. We also have installable packages and we 
frequently see issues with that. We are trying to solve some of them using PBI 
packages just so that each "package" always has it's dependencies in check.

Although we are just a "consumer", we'd rather have a single FreeBSD port that 
we build then 5 ports we need to update, with all the required dependencies.

Our github repo is split into one for packages, tools and pfSense. But each is 
really a standalone thing, because there is no overlap. Which probably my 
point, the plugin is useless without the main.

The one git repo for pfSense is pretty manageable, even more so through git 
with Pull requests. The single biggest jump in commits and patches from the 
community is moving to GitHub. It makes contributions so much easier. That 
said, even for us the amount of simultaneous active coders is about 5, although 
we do see small patches and pull requests from about 30 or so people a year.

I see nagios using nagios-plugins, that has seperate releases from the main 
nagios. So there's that too.

Just a few thoughts from the other end.

Really, really, _really_ looking forward to Viscosity and Tunnelblick shipping 
Ipv6 enabled clients. Pretty please.

Cheers,

Seth
pfSense developer

Op 13 mei 2012, om 13:12 heeft Gert Doering het volgende geschreven:

> Hi,
> 
> On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote:
 Can't we progress?
>>> 
>>> Why is that progress?
>>> 
>>> Change always has drawbacks.  If the plus sides outweighs the drawbacks,
>>> change is good.  Change for change's sake, "just because you can change
>>> it", is not.
>> 
>> Yes, but still from your responses I don't see any drawback... maybe I
>> am slow learner...
> 
> Drawback to maintainers and sysadmins has already been mentioned by
> ecrist and me.  Try being a sysadmin for a few weeks and figure out
> which bits of xorg you need to download to install xinit, assuming
> you have a system without any X libraries and headers yet (in the xorg
> example: splitting off "xinit" might actually make sense, but splitting
> the basic infrastructure to build anything into about 50 different
> "xyz-library" and "xyz-headers" packages is crazyness).
> 
> But the onus is not particularily on me: you have not put forward 
> convincing arguments why splitting off a very small number of files 
> that only make use in the context of OpenVPN into their own repository 
> has any *advantage*.
> 
> The handwavy argument "it will attract more users!" can be countered by
> similarily handwaving "I, as a user, hate to download multiple packages
> to figure out how to start contributing, and so it will scare *away*
> users".
> 
> 
> As a counterexample, look at Apache.  They have heaps of modules in
> the main tarball, and have no issues with frequent release and with
> attracting developers.  And still, modules maintained by non-apache
> developers can be developed externally, without having to splitt off
> all existing modules beforehand.
> 
> gert
> -- 
> USENET is *not* the non-clickable part of WWW!
>   //www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. 
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel




Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Alon Bar-Lev
On Sun, May 13, 2012 at 2:12 PM, Gert Doering  wrote:
> Hi,
>
> On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote:
>> >> Can't we progress?
>> >
>> > Why is that progress?
>> >
>> > Change always has drawbacks.  If the plus sides outweighs the drawbacks,
>> > change is good.  Change for change's sake, "just because you can change
>> > it", is not.
>>
>> Yes, but still from your responses I don't see any drawback... maybe I
>> am slow learner...
>
> Drawback to maintainers and sysadmins has already been mentioned by
> ecrist and me.  Try being a sysadmin for a few weeks and figure out
> which bits of xorg you need to download to install xinit, assuming
> you have a system without any X libraries and headers yet (in the xorg
> example: splitting off "xinit" might actually make sense, but splitting
> the basic infrastructure to build anything into about 50 different
> "xyz-library" and "xyz-headers" packages is crazyness).

First, I was gentoo developer for some time, and maintained, among
other, openvpn packages.
The case of xorg is not similar, you keep using this example while in
the openvpn case we have a core and a set of optional plugins, that's
all.
So please give appropriate example.

One example of your approach is the bluez project, which insist of
using in-tree plugins not because it is the simpler approach, but this
way it can enforce GPL license on all plugins and make sure they are
stay opened.

> But the onus is not particularily on me: you have not put forward
> convincing arguments why splitting off a very small number of files
> that only make use in the context of OpenVPN into their own repository
> has any *advantage*.

I think I already stated some advantages, you can ether accept or
reject but at least they are focus on the subject at hand:

1. we remove dependencies from the core openvpn package.

2. we can release a fix in plugin without releasing the complete openvpn.

3. plugins are optional, user may install the plugin as separate
pacakge if needed.

4. we can delegate maintenance of plugin.

5. we can attract more people to the community.

6. simpler to track the history of atomic components in the mean of
source control.

>
> The handwavy argument "it will attract more users!" can be countered by
> similarily handwaving "I, as a user, hate to download multiple packages
> to figure out how to start contributing, and so it will scare *away*
> users".

H... I think that you are at the xorg example again...

> As a counterexample, look at Apache.  They have heaps of modules in
> the main tarball, and have no issues with frequent release and with
> attracting developers.  And still, modules maintained by non-apache
> developers can be developed externally, without having to splitt off
> all existing modules beforehand.

OK... now you are talking... so you say that like apache we need to
integrate the plugins to main build system, this was the other
alternative.

>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>                                                           //www.muc.de/~gert/
> Gert Doering - Munich, Germany                             g...@greenie.muc.de
> fax: +49-89-35655025                        g...@net.informatik.tu-muenchen.de



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Gert Doering
Hi,

On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote:
> >> Can't we progress?
> >
> > Why is that progress?
> >
> > Change always has drawbacks.  If the plus sides outweighs the drawbacks,
> > change is good.  Change for change's sake, "just because you can change
> > it", is not.
> 
> Yes, but still from your responses I don't see any drawback... maybe I
> am slow learner...

Drawback to maintainers and sysadmins has already been mentioned by
ecrist and me.  Try being a sysadmin for a few weeks and figure out
which bits of xorg you need to download to install xinit, assuming
you have a system without any X libraries and headers yet (in the xorg
example: splitting off "xinit" might actually make sense, but splitting
the basic infrastructure to build anything into about 50 different
"xyz-library" and "xyz-headers" packages is crazyness).

But the onus is not particularily on me: you have not put forward 
convincing arguments why splitting off a very small number of files 
that only make use in the context of OpenVPN into their own repository 
has any *advantage*.

The handwavy argument "it will attract more users!" can be countered by
similarily handwaving "I, as a user, hate to download multiple packages
to figure out how to start contributing, and so it will scare *away*
users".


As a counterexample, look at Apache.  They have heaps of modules in
the main tarball, and have no issues with frequent release and with
attracting developers.  And still, modules maintained by non-apache
developers can be developed externally, without having to splitt off
all existing modules beforehand.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpQ0wf0Yb5VF.pgp
Description: PGP signature


Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Alon Bar-Lev
On Sun, May 13, 2012 at 12:35 PM, Gert Doering  wrote:
> Hi,
>
> On Sun, May 13, 2012 at 12:30:37PM +0300, Alon Bar-Lev wrote:
>> An healthy community dealing with openvpn need to gather all resources
>> that are acting at that niche.
>> There is no reason why we should not invite these maintainer to be
>> part of the openvpn project, on the contrary, we gain more resources,
>> more professionals.
>
> And how exactly will "fragment the openvpn source tree into many small
> packages" invite more contribution?
>
> I, for one, will think twice about contributing to a project where I have
> to figure out which of the 470 packages I need to download before I can
> even *start* looking at things.
>
>> Why should we define the scope of the openvpn project based on the
>> legacy james svn tree?
>
> Why not?
>
>> Can't we progress?
>
> Why is that progress?
>
> Change always has drawbacks.  If the plus sides outweighs the drawbacks,
> change is good.  Change for change's sake, "just because you can change
> it", is not.

Yes, but still from your responses I don't see any drawback... maybe I
am slow learner...
I try to summarize people view and get:

1. it is hard to push changes to specific git repository... it is not
actually hard though.

2. it is hard to maintain several packages at distro level, well, as
shown in the other examples and plugins it is not the case.

3. it will grow to 500 packages like xorg, while it is not the case
even in nightmares... and we are talking about pure optional
components.

>
>> I would like to see this community growing... all UI/management/plugin
>> developers working under the same roof.
>>
>> It is healthy to the project = more resources.
>> It is healthy to the users = one stop shop, better integration.
>
> *one stop*.  Thanks for saying that.  This is a strong argument against
> fragmenting our source tree.
>
> (I see you coming up with "why not have the different platform backends
> in their own repositories each, because a FreeBSD developer would not
> need the source files for Linux" next - and there is madness, not sanity)

Well, not for now :)
Although the thought came to mind when evaluating the polarssl implementation...

Alon.



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Gert Doering
Hi,

On Sun, May 13, 2012 at 12:30:37PM +0300, Alon Bar-Lev wrote:
> An healthy community dealing with openvpn need to gather all resources
> that are acting at that niche.
> There is no reason why we should not invite these maintainer to be
> part of the openvpn project, on the contrary, we gain more resources,
> more professionals.

And how exactly will "fragment the openvpn source tree into many small
packages" invite more contribution?

I, for one, will think twice about contributing to a project where I have
to figure out which of the 470 packages I need to download before I can
even *start* looking at things.

> Why should we define the scope of the openvpn project based on the
> legacy james svn tree?

Why not?

> Can't we progress?

Why is that progress?

Change always has drawbacks.  If the plus sides outweighs the drawbacks,
change is good.  Change for change's sake, "just because you can change
it", is not.

> I would like to see this community growing... all UI/management/plugin
> developers working under the same roof.
> 
> It is healthy to the project = more resources.
> It is healthy to the users = one stop shop, better integration.

*one stop*.  Thanks for saying that.  This is a strong argument against
fragmenting our source tree.

(I see you coming up with "why not have the different platform backends
in their own repositories each, because a FreeBSD developer would not
need the source files for Linux" next - and there is madness, not sanity)

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpI5pLTejoTq.pgp
Description: PGP signature


Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Alon Bar-Lev
On Sun, May 13, 2012 at 12:23 PM, Gert Doering  wrote:
> Hi,
>
> On Sun, May 13, 2012 at 12:10:48PM +0300, Alon Bar-Lev wrote:
>> And, if not split, they these two plugins should integrated within
>> build system.
>
> This is certainly true.
>
>> The custom make files are not doing any good, but I
>> still don't understand the difference between these two and other
>> plugins out there.
>
> They are maintained by the openvpn project, and other plugins are not.
>
> That difference should be quite obious, no?

This is exactly my point.

An healthy community dealing with openvpn need to gather all resources
that are acting at that niche.
There is no reason why we should not invite these maintainer to be
part of the openvpn project, on the contrary, we gain more resources,
more professionals.

Why should we define the scope of the openvpn project based on the
legacy james svn tree?
Can't we progress?

I would like to see this community growing... all UI/management/plugin
developers working under the same roof.

It is healthy to the project = more resources.
It is healthy to the users = one stop shop, better integration.

Alon.



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Gert Doering
Hi,

On Sun, May 13, 2012 at 12:10:48PM +0300, Alon Bar-Lev wrote:
> And, if not split, they these two plugins should integrated within
> build system. 

This is certainly true.

> The custom make files are not doing any good, but I
> still don't understand the difference between these two and other
> plugins out there.

They are maintained by the openvpn project, and other plugins are not.

That difference should be quite obious, no?

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpAG0N5jjRrL.pgp
Description: PGP signature


Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Alon Bar-Lev
On Sun, May 13, 2012 at 12:01 PM, Gert Doering  wrote:
> Try to build Xorg or teTeX yourself, from packages, and learn from it.

We are not xorg... [yet].
Anyway, I think the modular xorg and kde processes are a great success.
It allowed them to delegate maintenance, and handle shorter release
cycles for each component. Now people can update their xinit without
receiving ~50 unneeded changes. Stabilization process is also much
shorter now, as most of the components are static.

I showed Eric that the freebsd already maintains[1] the auth-radius,
auth-ldap in modular way. Not sure why the auth-pam and down-root are
any different.

We need to strive to join efforts with these other plugin maintainer,
hosting them on the openvpn project resources, and build healthy
community.

And, if not split, they these two plugins should integrated within
build system. The custom make files are not doing any good, but I
still don't understand the difference between these two and other
plugins out there.

Alon.

[1] http://www.freebsd.org/cgi/ports.cgi?query=openvpn=all



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-13 Thread Gert Doering
Hi,

On Sat, May 12, 2012 at 05:22:52PM -0400, Eric Crist wrote:
> My two cents on this is as follows:
> 
> As a package maintainer, I think this is going to prove to be a lot of 
> work.  It means there are more packages to maintain, over the one I 
> need to now.  

Yeah.  From a sysadmin perspective, super-modular projects like Xorg or
teTeX really make my life miserable - and I do not see particular gain
in moving things that are part of "the openvpn package" into separate 
projects.

(Windows TAP is fine, as it's really a project on its own, useful for
openvpn, but not that closely tied to it)

> HOWEVER, from the OpenVPN development process, I think it's best
> to split things out, as Alon suggests, with one caveat.  Let's wait
> for 3.0.  That's already going to be a massive change to our source
> tree and overall build process, and I think it would be the right
> time to push that out.

Even then.  Modular source doesn't mean everything gets fragmented in
500 teeny little packages where package maintainers or sysadmins have
to figure out which 395 of those they need, and which ones can be
skipped.

Try to build Xorg or teTeX yourself, from packages, and learn from it.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpUFAFWhNUmQ.pgp
Description: PGP signature


Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-12 Thread Eric Crist
My two cents on this is as follows:

As a package maintainer, I think this is going to prove to be a lot of work.  
It means there are more packages to maintain, over the one I need to now.  
HOWEVER, from the OpenVPN development process, I think it's best to split 
things out, as Alon suggests, with one caveat.  Let's wait for 3.0.  That's 
already going to be a massive change to our source tree and overall build 
process, and I think it would be the right time to push that out.

Hope this helps.
-
Eric F Crist



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-10 Thread Alon Bar-Lev
On Thu, May 10, 2012 at 3:42 PM, Alon Bar-Lev  wrote:
> On Thu, May 10, 2012 at 3:39 PM, David Sommerseth
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/05/12 14:33, Alon Bar-Lev wrote:
>>> On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen
>>>  wrote:

> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen
>  wrote:
>>> Hello David,
>>>
>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>>  wrote:
>>>
>>> 
>>>
 The reason I don't see the benefit of splitting out the
 plug-ins as much is that they all depend on OpenVPN.  You
 can not make much use of these plug-ins without having
 OpenVPN.  But with Windows TAP driver and easy-rsa, they
 can be completely used independently.

 Another point is that the plug-ins we have in the source
 tree, is officially supported plug-ins.  And especially
 auth-pam and down-root are plug-ins which are very useful
 and we should encourage packagers to always package
 those.

 Then the example/ and defer/ plug-ins, which are
 examples.  Maybe it would rather make sense to merge them
 somehow?
>>> There are a lot of plugins out there, think about chrome
>>> extension or firefox extension, but also network manager
>>> plugins or similar, they are all depend on the core
>>> product, but extend its functionality, and have their own
>>> repositories.
>>>
>>> Plugins should be installed as separate package, aka rpm.
>>>
>>> So if administrator wants openvpn he does: # yum install
>>> openvpn
>>>
>>> Now, if administrator wants auth-pam, he should do: # yum
>>> install openvpn-plugin-auth-pam
>>>
>>> As there is no sense in keeping the auth-pam plugin in
>>> system if it is unused nor to have pam dependency of the
>>> openvpn core package.
>>>
>>> I would not encourage packages to always have them, it is
>>> also not the correct approach for plugins. Plugins should
>>> be optional in nature.
>>>
>>> All the above does not imply separate repository as in both
>>> cases we can either provide one .spec file that generate
>>> both rpms or two separate spec files.
>>>
>>> The real question is how do we provide proper build for
>>> this components. Currently it has poor-man-build, which I
>>> fixed to meet some level of quality, instead of
>>> ./configure& install, packager should go and figure
>>> own what else needs to be built in tree.
>>>
>>> So either these are officially supported and should be
>>> build properly using main build system, example: --- $
>>> ./configure --enable-plugin-auth-pam PAM_CFLAGS=...
>>> PAM_LIBS=... ---
>>>
>>> Or have plugins as separate components with its own release
>>> cycle and should have their proper own build system and
>>> release cycle.
>>>
>>> I think that if we have proper interface
>>> (openvpn-plugin.h), there is no sense in providing the
>>> plugins within the tree, as it has its own release cycle.
>>>
>>> I also would like to discuss the "official" argument A
>>> project can have several repositories all at equal
>>> "official" level, why on earth people think that having
>>> more than one repository around damage their "official"
>>> state? "officially supported plug-ins", can be official in
>>> the openvpn repository and can be official in their own
>>> repository, there is absolutely no difference between the
>>> two approaches in this regards.
>>>
>>> However, splitting the repositories, allow helping distro
>>> packaging in determine what needed to be packaged and
>>> provided to users, it also allow separate release cycle
>>> (new openvpn release does not force new plugin release),
>>> and can even help in maintenance as a plugin can have its
>>> own maintainer (commit access).
>>>
>>> If also has more advantage as now in github we can
>>> encourage people to host and maintain their plugin within
>>> the OpenVPN organization, attracting more skills. So bottom
>>> line:
>>>
>>> 1. Either we add the plugins to core build system, with its
>>> disadvantages.
>>>
>>> 2. Split plugins into their own repository, release cycle,
>>> packaging.
>>>
>>> I am for (2), as I don't afraid of the "official" argument
>>> nor do I afraid to commit to more than one repository, and
>>> the modular nature of the plugin interface allows optional
>>> components to be installed separately along with their own
>>> dependencies.
>>>
>>> Alon
>> I think there's some very good argumentation here. In my
>> view, separating plugins into 

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-10 Thread Alon Bar-Lev
On Thu, May 10, 2012 at 3:39 PM, David Sommerseth
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/05/12 14:33, Alon Bar-Lev wrote:
>> On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen
>>  wrote:
>>>
 On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen
  wrote:
>> Hello David,
>>
>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>  wrote:
>>
>> 
>>
>>> The reason I don't see the benefit of splitting out the
>>> plug-ins as much is that they all depend on OpenVPN.  You
>>> can not make much use of these plug-ins without having
>>> OpenVPN.  But with Windows TAP driver and easy-rsa, they
>>> can be completely used independently.
>>>
>>> Another point is that the plug-ins we have in the source
>>> tree, is officially supported plug-ins.  And especially
>>> auth-pam and down-root are plug-ins which are very useful
>>> and we should encourage packagers to always package
>>> those.
>>>
>>> Then the example/ and defer/ plug-ins, which are
>>> examples.  Maybe it would rather make sense to merge them
>>> somehow?
>> There are a lot of plugins out there, think about chrome
>> extension or firefox extension, but also network manager
>> plugins or similar, they are all depend on the core
>> product, but extend its functionality, and have their own
>> repositories.
>>
>> Plugins should be installed as separate package, aka rpm.
>>
>> So if administrator wants openvpn he does: # yum install
>> openvpn
>>
>> Now, if administrator wants auth-pam, he should do: # yum
>> install openvpn-plugin-auth-pam
>>
>> As there is no sense in keeping the auth-pam plugin in
>> system if it is unused nor to have pam dependency of the
>> openvpn core package.
>>
>> I would not encourage packages to always have them, it is
>> also not the correct approach for plugins. Plugins should
>> be optional in nature.
>>
>> All the above does not imply separate repository as in both
>> cases we can either provide one .spec file that generate
>> both rpms or two separate spec files.
>>
>> The real question is how do we provide proper build for
>> this components. Currently it has poor-man-build, which I
>> fixed to meet some level of quality, instead of
>> ./configure& install, packager should go and figure
>> own what else needs to be built in tree.
>>
>> So either these are officially supported and should be
>> build properly using main build system, example: --- $
>> ./configure --enable-plugin-auth-pam PAM_CFLAGS=...
>> PAM_LIBS=... ---
>>
>> Or have plugins as separate components with its own release
>> cycle and should have their proper own build system and
>> release cycle.
>>
>> I think that if we have proper interface
>> (openvpn-plugin.h), there is no sense in providing the
>> plugins within the tree, as it has its own release cycle.
>>
>> I also would like to discuss the "official" argument A
>> project can have several repositories all at equal
>> "official" level, why on earth people think that having
>> more than one repository around damage their "official"
>> state? "officially supported plug-ins", can be official in
>> the openvpn repository and can be official in their own
>> repository, there is absolutely no difference between the
>> two approaches in this regards.
>>
>> However, splitting the repositories, allow helping distro
>> packaging in determine what needed to be packaged and
>> provided to users, it also allow separate release cycle
>> (new openvpn release does not force new plugin release),
>> and can even help in maintenance as a plugin can have its
>> own maintainer (commit access).
>>
>> If also has more advantage as now in github we can
>> encourage people to host and maintain their plugin within
>> the OpenVPN organization, attracting more skills. So bottom
>> line:
>>
>> 1. Either we add the plugins to core build system, with its
>> disadvantages.
>>
>> 2. Split plugins into their own repository, release cycle,
>> packaging.
>>
>> I am for (2), as I don't afraid of the "official" argument
>> nor do I afraid to commit to more than one repository, and
>> the modular nature of the plugin interface allows optional
>> components to be installed separately along with their own
>> dependencies.
>>
>> Alon
> I think there's some very good argumentation here. In my
> view, separating plugins into their own repositories would
> have some important advantages; excuse me for repeating some
> of Alon's arguments here:
>
> 1) Delegating maintenance tasks easily to (new) 

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-10 Thread David Sommerseth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/12 14:33, Alon Bar-Lev wrote:
> On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen
>  wrote:
>> 
>>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen
>>>  wrote:
> Hello David,
> 
> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth 
>  wrote:
> 
> 
> 
>> The reason I don't see the benefit of splitting out the
>> plug-ins as much is that they all depend on OpenVPN.  You
>> can not make much use of these plug-ins without having
>> OpenVPN.  But with Windows TAP driver and easy-rsa, they
>> can be completely used independently.
>> 
>> Another point is that the plug-ins we have in the source
>> tree, is officially supported plug-ins.  And especially
>> auth-pam and down-root are plug-ins which are very useful
>> and we should encourage packagers to always package
>> those.
>> 
>> Then the example/ and defer/ plug-ins, which are
>> examples.  Maybe it would rather make sense to merge them
>> somehow?
> There are a lot of plugins out there, think about chrome
> extension or firefox extension, but also network manager
> plugins or similar, they are all depend on the core
> product, but extend its functionality, and have their own
> repositories.
> 
> Plugins should be installed as separate package, aka rpm.
> 
> So if administrator wants openvpn he does: # yum install
> openvpn
> 
> Now, if administrator wants auth-pam, he should do: # yum
> install openvpn-plugin-auth-pam
> 
> As there is no sense in keeping the auth-pam plugin in
> system if it is unused nor to have pam dependency of the
> openvpn core package.
> 
> I would not encourage packages to always have them, it is
> also not the correct approach for plugins. Plugins should
> be optional in nature.
> 
> All the above does not imply separate repository as in both
> cases we can either provide one .spec file that generate
> both rpms or two separate spec files.
> 
> The real question is how do we provide proper build for
> this components. Currently it has poor-man-build, which I
> fixed to meet some level of quality, instead of
> ./configure& install, packager should go and figure
> own what else needs to be built in tree.
> 
> So either these are officially supported and should be
> build properly using main build system, example: --- $
> ./configure --enable-plugin-auth-pam PAM_CFLAGS=...
> PAM_LIBS=... ---
> 
> Or have plugins as separate components with its own release
> cycle and should have their proper own build system and
> release cycle.
> 
> I think that if we have proper interface
> (openvpn-plugin.h), there is no sense in providing the
> plugins within the tree, as it has its own release cycle.
> 
> I also would like to discuss the "official" argument A
> project can have several repositories all at equal
> "official" level, why on earth people think that having
> more than one repository around damage their "official"
> state? "officially supported plug-ins", can be official in
> the openvpn repository and can be official in their own 
> repository, there is absolutely no difference between the
> two approaches in this regards.
> 
> However, splitting the repositories, allow helping distro
> packaging in determine what needed to be packaged and
> provided to users, it also allow separate release cycle
> (new openvpn release does not force new plugin release),
> and can even help in maintenance as a plugin can have its
> own maintainer (commit access).
> 
> If also has more advantage as now in github we can
> encourage people to host and maintain their plugin within
> the OpenVPN organization, attracting more skills. So bottom
> line:
> 
> 1. Either we add the plugins to core build system, with its
> disadvantages.
> 
> 2. Split plugins into their own repository, release cycle,
> packaging.
> 
> I am for (2), as I don't afraid of the "official" argument
> nor do I afraid to commit to more than one repository, and
> the modular nature of the plugin interface allows optional
> components to be installed separately along with their own
> dependencies.
> 
> Alon
 I think there's some very good argumentation here. In my
 view, separating plugins into their own repositories would
 have some important advantages; excuse me for repeating some
 of Alon's arguments here:
 
 1) Delegating maintenance tasks easily to (new) developers:
 this is now trivial with GitHub 2) Avoid having to make an
 OpenVPN release due to an important fix in a plugin used by
 few. This also helps distro packagers, 

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-10 Thread Alon Bar-Lev
On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen  wrote:
>
>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen  wrote:
 Hello David,

 On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
  wrote:

 

> The reason I don't see the benefit of splitting out the plug-ins as
> much is that they all depend on OpenVPN.  You can not make much use of
> these plug-ins without having OpenVPN.  But with Windows TAP driver
> and easy-rsa, they can be completely used independently.
>
> Another point is that the plug-ins we have in the source tree, is
> officially supported plug-ins.  And especially auth-pam and down-root
> are plug-ins which are very useful and we should encourage packagers
> to always package those.
>
> Then the example/ and defer/ plug-ins, which are examples.  Maybe it
> would rather make sense to merge them somehow?
 There are a lot of plugins out there, think about chrome extension or
 firefox extension, but also network manager plugins or similar, they
 are all depend on the core product, but extend its functionality, and
 have their own repositories.

 Plugins should be installed as separate package, aka rpm.

 So if administrator wants openvpn he does:
 # yum install openvpn

 Now, if administrator wants auth-pam, he should do:
 # yum install openvpn-plugin-auth-pam

 As there is no sense in keeping the auth-pam plugin in system if it is
 unused nor to have pam dependency of the openvpn core package.

 I would not encourage packages to always have them, it is also not the
 correct approach for plugins. Plugins should be optional in nature.

 All the above does not imply separate repository as in both cases we
 can either provide one .spec file that generate both rpms or two
 separate spec files.

 The real question is how do we provide proper build for this
 components. Currently it has poor-man-build, which I fixed to meet
 some level of quality, instead of ./configure& install, packager
 should go and figure own what else needs to be built in tree.

 So either these are officially supported and should be build properly
 using main build system, example:
 ---
 $ ./configure --enable-plugin-auth-pam PAM_CFLAGS=... PAM_LIBS=...
 ---

 Or have plugins as separate components with its own release cycle and
 should have their proper own build system and release cycle.

 I think that if we have proper interface (openvpn-plugin.h), there is
 no sense in providing the plugins within the tree, as it has its own
 release cycle.

 I also would like to discuss the "official" argument
 A project can have several repositories all at equal "official" level,
 why on earth people think that having more than one repository around
 damage their "official" state? "officially supported plug-ins", can be
 official in the openvpn repository and can be official in their own
 repository, there is absolutely no difference between the two
 approaches in this regards.

 However, splitting the repositories, allow helping distro packaging in
 determine what needed to be packaged and provided to users, it also
 allow separate release cycle (new openvpn release does not force new
 plugin release), and can even help in maintenance as a plugin can have
 its own maintainer (commit access).

 If also has more advantage as now in github we can encourage people to
 host and maintain their plugin within the OpenVPN organization,
 attracting more skills.
 So bottom line:

 1. Either we add the plugins to core build system, with its disadvantages.

 2. Split plugins into their own repository, release cycle, packaging.

 I am for (2), as I don't afraid of the "official" argument nor do I
 afraid to commit to more than one repository, and the modular nature
 of the plugin interface allows optional components to be installed
 separately along with their own dependencies.

 Alon
>>> I think there's some very good argumentation here. In my view,
>>> separating plugins into their own repositories would have some important
>>> advantages; excuse me for repeating some of Alon's arguments here:
>>>
>>> 1) Delegating maintenance tasks easily to (new) developers: this is now
>>> trivial with GitHub
>>> 2) Avoid having to make an OpenVPN release due to an important fix in a
>>> plugin used by few. This also helps distro packagers, provided they
>>> didn't bundle the plugins in their core "openvpn" package
>>>
>>> Afaik none of the official plugins are needed to create the official
>>> Windows installers, so that platform is entirely unaffected. On *NIX
>>> side we only release source code. If we don't want to force people to

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-10 Thread Samuli Seppänen

> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen  wrote:
>>> Hello David,
>>>
>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>>  wrote:
>>>
>>> 
>>>
 The reason I don't see the benefit of splitting out the plug-ins as
 much is that they all depend on OpenVPN.  You can not make much use of
 these plug-ins without having OpenVPN.  But with Windows TAP driver
 and easy-rsa, they can be completely used independently.

 Another point is that the plug-ins we have in the source tree, is
 officially supported plug-ins.  And especially auth-pam and down-root
 are plug-ins which are very useful and we should encourage packagers
 to always package those.

 Then the example/ and defer/ plug-ins, which are examples.  Maybe it
 would rather make sense to merge them somehow?
>>> There are a lot of plugins out there, think about chrome extension or
>>> firefox extension, but also network manager plugins or similar, they
>>> are all depend on the core product, but extend its functionality, and
>>> have their own repositories.
>>>
>>> Plugins should be installed as separate package, aka rpm.
>>>
>>> So if administrator wants openvpn he does:
>>> # yum install openvpn
>>>
>>> Now, if administrator wants auth-pam, he should do:
>>> # yum install openvpn-plugin-auth-pam
>>>
>>> As there is no sense in keeping the auth-pam plugin in system if it is
>>> unused nor to have pam dependency of the openvpn core package.
>>>
>>> I would not encourage packages to always have them, it is also not the
>>> correct approach for plugins. Plugins should be optional in nature.
>>>
>>> All the above does not imply separate repository as in both cases we
>>> can either provide one .spec file that generate both rpms or two
>>> separate spec files.
>>>
>>> The real question is how do we provide proper build for this
>>> components. Currently it has poor-man-build, which I fixed to meet
>>> some level of quality, instead of ./configure& install, packager
>>> should go and figure own what else needs to be built in tree.
>>>
>>> So either these are officially supported and should be build properly
>>> using main build system, example:
>>> ---
>>> $ ./configure --enable-plugin-auth-pam PAM_CFLAGS=... PAM_LIBS=...
>>> ---
>>>
>>> Or have plugins as separate components with its own release cycle and
>>> should have their proper own build system and release cycle.
>>>
>>> I think that if we have proper interface (openvpn-plugin.h), there is
>>> no sense in providing the plugins within the tree, as it has its own
>>> release cycle.
>>>
>>> I also would like to discuss the "official" argument
>>> A project can have several repositories all at equal "official" level,
>>> why on earth people think that having more than one repository around
>>> damage their "official" state? "officially supported plug-ins", can be
>>> official in the openvpn repository and can be official in their own
>>> repository, there is absolutely no difference between the two
>>> approaches in this regards.
>>>
>>> However, splitting the repositories, allow helping distro packaging in
>>> determine what needed to be packaged and provided to users, it also
>>> allow separate release cycle (new openvpn release does not force new
>>> plugin release), and can even help in maintenance as a plugin can have
>>> its own maintainer (commit access).
>>>
>>> If also has more advantage as now in github we can encourage people to
>>> host and maintain their plugin within the OpenVPN organization,
>>> attracting more skills.
>>> So bottom line:
>>>
>>> 1. Either we add the plugins to core build system, with its disadvantages.
>>>
>>> 2. Split plugins into their own repository, release cycle, packaging.
>>>
>>> I am for (2), as I don't afraid of the "official" argument nor do I
>>> afraid to commit to more than one repository, and the modular nature
>>> of the plugin interface allows optional components to be installed
>>> separately along with their own dependencies.
>>>
>>> Alon
>> I think there's some very good argumentation here. In my view,
>> separating plugins into their own repositories would have some important
>> advantages; excuse me for repeating some of Alon's arguments here:
>>
>> 1) Delegating maintenance tasks easily to (new) developers: this is now
>> trivial with GitHub
>> 2) Avoid having to make an OpenVPN release due to an important fix in a
>> plugin used by few. This also helps distro packagers, provided they
>> didn't bundle the plugins in their core "openvpn" package
>>
>> Afaik none of the official plugins are needed to create the official
>> Windows installers, so that platform is entirely unaffected. On *NIX
>> side we only release source code. If we don't want to force people to
>> fetch official plugin code using Git, providing tarballs would be trivial.
>>
>> I tend to agree that packagers should take care of packaging the plugins
>> as they see fit and 

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-08 Thread Samuli Seppänen

> Hello David,
>
> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>  wrote:
>
> 
>
>> The reason I don't see the benefit of splitting out the plug-ins as
>> much is that they all depend on OpenVPN.  You can not make much use of
>> these plug-ins without having OpenVPN.  But with Windows TAP driver
>> and easy-rsa, they can be completely used independently.
>>
>> Another point is that the plug-ins we have in the source tree, is
>> officially supported plug-ins.  And especially auth-pam and down-root
>> are plug-ins which are very useful and we should encourage packagers
>> to always package those.
>>
>> Then the example/ and defer/ plug-ins, which are examples.  Maybe it
>> would rather make sense to merge them somehow?
> There are a lot of plugins out there, think about chrome extension or
> firefox extension, but also network manager plugins or similar, they
> are all depend on the core product, but extend its functionality, and
> have their own repositories.
>
> Plugins should be installed as separate package, aka rpm.
>
> So if administrator wants openvpn he does:
> # yum install openvpn
>
> Now, if administrator wants auth-pam, he should do:
> # yum install openvpn-plugin-auth-pam
>
> As there is no sense in keeping the auth-pam plugin in system if it is
> unused nor to have pam dependency of the openvpn core package.
>
> I would not encourage packages to always have them, it is also not the
> correct approach for plugins. Plugins should be optional in nature.
>
> All the above does not imply separate repository as in both cases we
> can either provide one .spec file that generate both rpms or two
> separate spec files.
>
> The real question is how do we provide proper build for this
> components. Currently it has poor-man-build, which I fixed to meet
> some level of quality, instead of ./configure& install, packager
> should go and figure own what else needs to be built in tree.
>
> So either these are officially supported and should be build properly
> using main build system, example:
> ---
> $ ./configure --enable-plugin-auth-pam PAM_CFLAGS=... PAM_LIBS=...
> ---
>
> Or have plugins as separate components with its own release cycle and
> should have their proper own build system and release cycle.
>
> I think that if we have proper interface (openvpn-plugin.h), there is
> no sense in providing the plugins within the tree, as it has its own
> release cycle.
>
> I also would like to discuss the "official" argument
> A project can have several repositories all at equal "official" level,
> why on earth people think that having more than one repository around
> damage their "official" state? "officially supported plug-ins", can be
> official in the openvpn repository and can be official in their own
> repository, there is absolutely no difference between the two
> approaches in this regards.
>
> However, splitting the repositories, allow helping distro packaging in
> determine what needed to be packaged and provided to users, it also
> allow separate release cycle (new openvpn release does not force new
> plugin release), and can even help in maintenance as a plugin can have
> its own maintainer (commit access).
>
> If also has more advantage as now in github we can encourage people to
> host and maintain their plugin within the OpenVPN organization,
> attracting more skills.
> So bottom line:
>
> 1. Either we add the plugins to core build system, with its disadvantages.
>
> 2. Split plugins into their own repository, release cycle, packaging.
>
> I am for (2), as I don't afraid of the "official" argument nor do I
> afraid to commit to more than one repository, and the modular nature
> of the plugin interface allows optional components to be installed
> separately along with their own dependencies.
>
> Alon

I think there's some very good argumentation here. In my view,
separating plugins into their own repositories would have some important
advantages; excuse me for repeating some of Alon's arguments here:

1) Delegating maintenance tasks easily to (new) developers: this is now
trivial with GitHub
2) Avoid having to make an OpenVPN release due to an important fix in a
plugin used by few. This also helps distro packagers, provided they
didn't bundle the plugins in their core "openvpn" package

Afaik none of the official plugins are needed to create the official
Windows installers, so that platform is entirely unaffected. On *NIX
side we only release source code. If we don't want to force people to
fetch official plugin code using Git, providing tarballs would be trivial.

I tend to agree that packagers should take care of packaging the plugins
as they see fit and making sure they're compatible with their version of
OpenVPN. For example, on Debian/Ubuntu the OpenVPN package includes
"down-root" and "pam" plugins by default. However, I've never used
those, and I know many others who don't either. Having the plugins in
separate repositories would steer packagers to 

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-07 Thread Alon Bar-Lev
Hello David,

On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
 wrote:



> The reason I don't see the benefit of splitting out the plug-ins as
> much is that they all depend on OpenVPN.  You can not make much use of
> these plug-ins without having OpenVPN.  But with Windows TAP driver
> and easy-rsa, they can be completely used independently.
>
> Another point is that the plug-ins we have in the source tree, is
> officially supported plug-ins.  And especially auth-pam and down-root
> are plug-ins which are very useful and we should encourage packagers
> to always package those.
>
> Then the example/ and defer/ plug-ins, which are examples.  Maybe it
> would rather make sense to merge them somehow?

There are a lot of plugins out there, think about chrome extension or
firefox extension, but also network manager plugins or similar, they
are all depend on the core product, but extend its functionality, and
have their own repositories.

Plugins should be installed as separate package, aka rpm.

So if administrator wants openvpn he does:
# yum install openvpn

Now, if administrator wants auth-pam, he should do:
# yum install openvpn-plugin-auth-pam

As there is no sense in keeping the auth-pam plugin in system if it is
unused nor to have pam dependency of the openvpn core package.

I would not encourage packages to always have them, it is also not the
correct approach for plugins. Plugins should be optional in nature.

All the above does not imply separate repository as in both cases we
can either provide one .spec file that generate both rpms or two
separate spec files.

The real question is how do we provide proper build for this
components. Currently it has poor-man-build, which I fixed to meet
some level of quality, instead of ./configure& install, packager
should go and figure own what else needs to be built in tree.

So either these are officially supported and should be build properly
using main build system, example:
---
$ ./configure --enable-plugin-auth-pam PAM_CFLAGS=... PAM_LIBS=...
---

Or have plugins as separate components with its own release cycle and
should have their proper own build system and release cycle.

I think that if we have proper interface (openvpn-plugin.h), there is
no sense in providing the plugins within the tree, as it has its own
release cycle.

I also would like to discuss the "official" argument
A project can have several repositories all at equal "official" level,
why on earth people think that having more than one repository around
damage their "official" state? "officially supported plug-ins", can be
official in the openvpn repository and can be official in their own
repository, there is absolutely no difference between the two
approaches in this regards.

However, splitting the repositories, allow helping distro packaging in
determine what needed to be packaged and provided to users, it also
allow separate release cycle (new openvpn release does not force new
plugin release), and can even help in maintenance as a plugin can have
its own maintainer (commit access).

If also has more advantage as now in github we can encourage people to
host and maintain their plugin within the OpenVPN organization,
attracting more skills.

So bottom line:

1. Either we add the plugins to core build system, with its disadvantages.

2. Split plugins into their own repository, release cycle, packaging.

I am for (2), as I don't afraid of the "official" argument nor do I
afraid to commit to more than one repository, and the modular nature
of the plugin interface allows optional components to be installed
separately along with their own dependencies.

Alon



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-07 Thread Alon Bar-Lev
On Mon, May 7, 2012 at 10:23 AM, Adriaan de Jong <dej...@fox-it.com> wrote:
>> -Original Message-
>> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>> Sent: zondag 6 mei 2012 18:55
>> To: openvpn-devel@lists.sourceforge.net
>> Subject: [Openvpn-devel] [RFC] Split plugins into their own
>> repositories
>>
>> Hello,
>>
>> Now, I also have the courage to ask one more question regarding
>> build
>>
>> We currently have:
>> - auth-pam
>> - defer
>> - down-root
>> - examples
>>
>> Distribution wise it will be best to allow admin to install plugins as
>> own package which requires openvpn, allowing select specific plugins,
>> while each has own release cycle and versioning.
>>
>> I already made the openvpn-plugin.h available in /usr/include, so there
>> is no real reason to keep the plugins in openvpn tree, as they can be
>> complied using their own separate build system.
>>
>> for example, if we take RHEL, we can install the following to use the
>> auth-pam plugin:
>>
>> openvpn
>> openvpn-plugin-auth-pam
>>
>> To build plugin we need openvpn-devel.
>>
>> What do you say?
>>
>> BTW: next will be probably to split out the contrib... :)
>>
>> Alon
>>
>
> Aren't we going a little far in the whole splitting business? I though 
> splitting the build system off was already taking it a too far.
>
> These plugin and contrib. directories are directly related to the current 
> version of OpenVPN. Having them in the same tree, especially one that has 
> already been cleaned up by giving it a separate src directory.
>
> My vote therefore goes towards keeping them inline!
>
> Adriaan

Hello Andriaan,

Can you please explain what exactly is business? And what is
relationship between business and number of repositories? And why
business was split?

The only "build" system that was split was the windows PACKAGING which
is not the build system, as both the MSVC build system and the
autotools build system are part of the openvpn repository.

Now, is there any advantage in keeping the windows PACKAGING within
the same repository if its release cycle is totally atomic and
unrelated to openvpn maintenance? Can you please share some thought
with me, I really interested to understand how this lower
productivity?

Same for splitting out the tap-windows driver, I cannot think of any
single argument why this was needed to be within same repository of
openvpn, as it has its own version, release cycle and potential
maintainer. And there are other projects out there that needs only the
tap-windows, so providing own release cycle and installer only make it
more usable.

So before we discuss the benefit of splitting more component, I am
very interested to understand how current process went too far,
meaning productivity of the openvpn project maintenance was damaged.

Regards,
Alon.



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-07 Thread David Sommerseth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/05/12 18:55, Alon Bar-Lev wrote:
> Hello,
> 
> Now, I also have the courage to ask one more question regarding
> build
> 
> We currently have: - auth-pam - defer - down-root - examples
> 
> Distribution wise it will be best to allow admin to install plugins
> as own package which requires openvpn, allowing select specific
> plugins, while each has own release cycle and versioning.
> 
> I already made the openvpn-plugin.h available in /usr/include, so 
> there is no real reason to keep the plugins in openvpn tree, as
> they can be complied using their own separate build system.
> 
> for example, if we take RHEL, we can install the following to use
> the auth-pam plugin:
> 
> openvpn openvpn-plugin-auth-pam
> 
> To build plugin we need openvpn-devel.
> 
> What do you say?

I am not quite sure I see the benefit of this.  Just let me first
explain why I find the current splits fine.

- - Splitting out windows build stuff made sense, as openvpn is buildable
  in a autotools capable environment and windows build is really
  something completely different - and this simplifies the OpenVPN code
  base and fixing issues in the build tool chain don't require releasing
  a completely new OpenVPN version.

- - Splitting out Windows TAP driver also made sense, as that's something
  which does not depend on OpenVPN and can be used by other applications
  as well as OpenVPN.  I think of it as a network driver.

- - easy-rsa also made sense, as that's not strictly OpenVPN connected
  and is an alternative to other CA management software.  It only
  provides a module which is needed in OpenVPN if you want PKI/TLS and
  don't have any other CA management system in place already.

The reason I don't see the benefit of splitting out the plug-ins as
much is that they all depend on OpenVPN.  You can not make much use of
these plug-ins without having OpenVPN.  But with Windows TAP driver
and easy-rsa, they can be completely used independently.

Another point is that the plug-ins we have in the source tree, is
officially supported plug-ins.  And especially auth-pam and down-root
are plug-ins which are very useful and we should encourage packagers
to always package those.

Then the example/ and defer/ plug-ins, which are examples.  Maybe it
would rather make sense to merge them somehow?

> BTW: next will be probably to split out the contrib... :)

I would say much of the same logic is valid here as well.  These are
contributed scripts which are useful only when being used in context
with OpenVPN.  And it's not a big maintenance burden having them in
the openvpn tree at all.  And if there are updates here, it's more
natural for me to ship these together with a new OpenVPN version too.

So, I'm in favour of keeping both plug-ins and contrib in the tree as
it is now.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+nerYACgkQDC186MBRfrrMdwCeJ/k8VhlggCQFwKRM0h3r/Z3j
RxUAn1XJ/2HXL7sSy0P1aQI6XegEVlrB
=QrJp
-END PGP SIGNATURE-



Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-07 Thread Adriaan de Jong
> -Original Message-
> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
> Sent: zondag 6 mei 2012 18:55
> To: openvpn-devel@lists.sourceforge.net
> Subject: [Openvpn-devel] [RFC] Split plugins into their own
> repositories
> 
> Hello,
> 
> Now, I also have the courage to ask one more question regarding
> build
> 
> We currently have:
> - auth-pam
> - defer
> - down-root
> - examples
> 
> Distribution wise it will be best to allow admin to install plugins as
> own package which requires openvpn, allowing select specific plugins,
> while each has own release cycle and versioning.
> 
> I already made the openvpn-plugin.h available in /usr/include, so there
> is no real reason to keep the plugins in openvpn tree, as they can be
> complied using their own separate build system.
> 
> for example, if we take RHEL, we can install the following to use the
> auth-pam plugin:
> 
> openvpn
> openvpn-plugin-auth-pam
> 
> To build plugin we need openvpn-devel.
> 
> What do you say?
> 
> BTW: next will be probably to split out the contrib... :)
> 
> Alon
> 

Aren't we going a little far in the whole splitting business? I though 
splitting the build system off was already taking it a too far. 

These plugin and contrib. directories are directly related to the current 
version of OpenVPN. Having them in the same tree, especially one that has 
already been cleaned up by giving it a separate src directory.

My vote therefore goes towards keeping them inline!

Adriaan



[Openvpn-devel] [RFC] Split plugins into their own repositories

2012-05-06 Thread Alon Bar-Lev
Hello,

Now, I also have the courage to ask one more question regarding build

We currently have:
- auth-pam
- defer
- down-root
- examples

Distribution wise it will be best to allow admin to install plugins as
own package which requires openvpn, allowing select specific plugins,
while each has own release cycle and versioning.

I already made the openvpn-plugin.h available in /usr/include, so
there is no real reason to keep the plugins in openvpn tree, as they
can be complied using their own separate build system.

for example, if we take RHEL, we can install the following to use the
auth-pam plugin:

openvpn
openvpn-plugin-auth-pam

To build plugin we need openvpn-devel.

What do you say?

BTW: next will be probably to split out the contrib... :)

Alon