On Thu, May 10, 2012 at 3:42 PM, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > On Thu, May 10, 2012 at 3:39 PM, David Sommerseth > <openvpn.l...@topphemmelig.net> 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 >>> <sam...@openvpn.net> wrote: >>>> >>>>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen >>>>> <sam...@openvpn.net> wrote: >>>>>>> Hello David, >>>>>>> >>>>>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth >>>>>>> <openvpn.l...@topphemmelig.net> wrote: >>>>>>> >>>>>>> <snip> >>>>>>> >>>>>>>> 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&&make 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 the (in my >>>>>> opinion) right direction of packaging optional functionality >>>>>> as optional packages. They already do this for some of the >>>>>> off-tree plugins: >>>>>> >>>>>> <https://community.openvpn.net/openvpn/wiki/RelatedProjects> >>>>>> >>>>>> I believe the primary reason why the "pam" and "down-root" >>>>>> plugins are in OpenVPN repository is that they seem to come >>>>>> from James, who has a use-case for them. Personally, I would >>>>>> rather see the plugins in their own repositories, even if >>>>>> only to see if it fosters collaboration. >>>>>> >>>>>> I guess that was my 5 cents :). >>>>>> >>>>>> -- Samuli Seppänen Community Manager OpenVPN Technologies, >>>>>> Inc >>>>>> >>>>>> irc freenode net: mattock >>>>>> >>>>> Hello, >>>>> >>>>> In order to break the fear I just went ahead and did this... >>>>> maybe this will relax some of the concerns... >>>>> >>>>> A plugin in own repository, own build system, own rpm packaging >>>>> of auth-pam[1] and down-root[2], even ebuilds[3][4]! >>>>> >>>>> Now we have the following packages for rpm based system: >>>>> >>>>> - openvpn - openvpn-devel (openvpn-plugin.h) - >>>>> openvpn-plugin-auth-pam (introduces the pam dependency) - >>>>> openvpn-plugin-down-root >>>>> >>>>> I've prepared a openvpn branch[5] to support this migration, I >>>>> think that the best example is to see how the rpm spec file >>>>> was simplified[6], no none standard statement, simple configure >>>>> and make process, less dependencies for core package. >>>>> >>>>> I think that in the Gentoo ebuild[7] we can see more verbose >>>>> example, especially the following statement that is about to be >>>>> removed: --- if ! use minimal ; then cd src/plugins for i in *; >>>>> do [[ ${i} == "README" || ${i} == "examples" || ${i} == "defer" >>>>> ]] && continue [[ ${i} == "auth-pam" ]] && ! use pam && >>>>> continue einfo "Building ${i} plugin" emake -C "${i}" >>>>> CC="$(tc-getCC)" CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" done >>>>> cd .. --- >>>>> >>>>> I truly hope you see the advantage in building and packaging >>>>> each independent component by its own, the simplicity it >>>>> introduces in term of code maintenance and system >>>>> administration. Again, there is no impact of the official level >>>>> of the components. >>>>> >>>>> Best Regards, Alon Bar-Lev. >>>>> >>>>> [1] https://github.com/OpenVPN/openvpn-plugin-auth-pam [2] >>>>> https://github.com/OpenVPN/openvpn-plugin-down-root [3] >>>>> https://github.com/alonbl/alon-barlev-overlay/blob/master/net-misc/openvpn-plugin-auth-pam/openvpn-plugin-auth-pam-9999.ebuild >>>>> >>>>> >> [4] >> https://github.com/alonbl/alon-barlev-overlay/blob/master/net-misc/openvpn-plugin-down-root/openvpn-plugin-down-root-9999.ebuild >>>>> [5] https://github.com/alonbl/openvpn/compare/master...plugins >>>>> [6] >>>>> https://github.com/alonbl/openvpn/commit/0a9a1e1f234dcc81d4ed9ece5f894cfe5ec02d01#diff-0 >>>>> >>>>> >> [7[ >> https://github.com/alonbl/alon-barlev-overlay/blob/master/net-misc/openvpn/openvpn-9999.ebuild >>>> >>>> Hi Alon, >>>> >>>> Ok, so this is kind of a preview, which I think is fine. We >>>> should definitely look at these plugin repositories and see how >>>> it all fits together. I only got one minor nitpick... I think >>>> your own ("alonbl") GitHub repos would have been a more >>>> appropriate place for these plugin repositories for now, as >>>> they're not "officially" approved yet. >>>> >>>> -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc >>>> >>>> irc freenode net: mattock >>>> >>> >>> Well, among others, the mission was to create a community around >>> openvpn with extras, so that people will find VPN resources at one >>> place... >> >> Agreed. >> >>> What official or not, who is the maintainer of what, what level of >>> release and what the level of support should be documented in the >>> wiki or other place. >> >> We have not reached any agreement on splitting out the plug-ins or >> not. So putting them in an area which can be understood as a official >> repository is not okay. >> >>> If you want, I can remove these, no problem, but I needed to raise >>> these arguments. >> >> Please put them in your own repository, and what we put under the >> OpenVPN organisation part will be what we have as official repositories. >> > > I will. > But how can you agree the above... :) > > Anyway, I would like to get your updated response on this split... > > Alon.
Done, repositories are now at: https://github.com/alonbl/openvpn-plugin-auth-pam-private https://github.com/alonbl/openvpn-plugin-auth-pam-private I added -private suffix to reduce people sensitivity or fear that this is already done thing. Although I still waiting for some stronger arguments against. Regards, Alon
