[Openvpn-devel] Disable tun-ipv6 warning

[Arne Schwabe]

Hey,

Openvpn will show the following warning, if I enable tun-ipv6 in the
local config and not remote or vice versa:

WARNING: 'tun-ipv6' is present in remote config but missing in local
config, remote='tun-ipv6'

>From my understanding a ipv6 capable tun interface is always capable of
ipv4 only. (On android there is no difference at all). Even without
explicitly stating "tun-ipv6" openvpn will happily configure the ipv6
options. Is there anything this message warns about? (I know the obvious
the configs do not match).

If the server does not push any ipv6 related messages running with
tun-ipv6 works fine, and if the server does push ipv6 messages it works
fine too.

Forgive me if I am missing something obvious.

Arne

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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