You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jean-Marc Borer <jm...@gmail.com> on 2020/02/05 13:46:12 UTC
Re: Update centers based on mirrors are a nightmare to support in an
enterprise environment
Any opinion here?
For us, mirrors are just giving us headaches for plugins and updates...
On Thu, Jan 30, 2020 at 2:55 PM Jean-Marc Borer <jm...@gmail.com> wrote:
> Hi guys,
>
> This is bit of a complaint addressed to the NB infra community. When you
> are stuck behind corporate proxy that is very aggressively filtering web
> content, mirrors are a nightmare for you. In my case we need to whitelist
> every single server hosting java binaries otherwise we get empty files. As
> such, it is not viable to declare every single mirror (the company won't
> accept that).
>
> So my request is: please for NB IDE updates and their core components,
> never ever use mirrors or provide an option to always point to the same
> mirrored site.
>
> This may sound silly, but is really an issue within enterprises and
> therefore prevent the adoption of NB IDE far more than the alternatives,
> which is really a pity...
>
> Regards,
>
> JMB
>
Re: Update centers based on mirrors are a nightmare to support in an
enterprise environment
Posted by Jean-Marc Borer <jm...@gmail.com>.
Well, correct me if I am wrong, but the update center index itself is not
hosted on the mirrors. You get redirected from the links provided in the
index. And that is the issue for us.
On Wed, Feb 5, 2020 at 9:06 PM Laszlo Kishalmi <la...@gmail.com>
wrote:
> I think the best way would be mirror the update center from one specific
> mirror (or might be even from the dist) internally in the corporation,
> then set up that one as an update center.
>
> You might wrote a very minimal plugin to set that UC up for everyone if
> there are a lot of people involved.
>
> On 2/5/20 12:00 PM, Neil C Smith wrote:
> > On Wed, 5 Feb 2020, 14:21 Peter Kovacs, <Pe...@apache.org> wrote:
> >
> >> The ASF publishes the releases at:
> >>
> >> https://apache.org/dist/netbeans/
> >>
> >> Maybe that is less of an issue?
> >>
> > That's an option, keeping in mind the limits here if there's a lot of
> > corporate use though - https://www.apache.org/dev/infra-ban.html
> >
> > Otherwise maybe local mirroring?
> >
> > Best wishes,
> >
> > Neil
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Update centers based on mirrors are a nightmare to support in an
enterprise environment
Posted by Laszlo Kishalmi <la...@gmail.com>.
I think the best way would be mirror the update center from one specific
mirror (or might be even from the dist) internally in the corporation,
then set up that one as an update center.
You might wrote a very minimal plugin to set that UC up for everyone if
there are a lot of people involved.
On 2/5/20 12:00 PM, Neil C Smith wrote:
> On Wed, 5 Feb 2020, 14:21 Peter Kovacs, <Pe...@apache.org> wrote:
>
>> The ASF publishes the releases at:
>>
>> https://apache.org/dist/netbeans/
>>
>> Maybe that is less of an issue?
>>
> That's an option, keeping in mind the limits here if there's a lot of
> corporate use though - https://www.apache.org/dev/infra-ban.html
>
> Otherwise maybe local mirroring?
>
> Best wishes,
>
> Neil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Update centers based on mirrors are a nightmare to support in
an enterprise environment
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Mittwoch, den 05.02.2020, 20:00 +0000 schrieb Neil C Smith:
> On Wed, 5 Feb 2020, 14:21 Peter Kovacs, <Pe...@apache.org> wrote:
>
> > The ASF publishes the releases at:
> >
> > https://apache.org/dist/netbeans/
> >
> > Maybe that is less of an issue?
> >
>
> That's an option, keeping in mind the limits here if there's a lot of
> corporate use though - https://www.apache.org/dev/infra-ban.html
>
I don't like hitting the core infrastructure harder because some
network equipment vendor (or its administrators) screwed up (no there
is no reason to configure a proxy as described).
But I have an idea to work around this ugly problem:
Instead of serving a static update center catalog from the netbeans-vm
we could generate the update catalog based on a template. The idea is
this.
A call like this:
curl --output - https://netbeans-vm.apache.org/uc/11.1/updates.xml.gz | gzip -d
would still yield:
<!-- ... --->
<module codenamebase="org.netbeans.modules.xml.tools"
distribution="ide/org-netbeans-modules-xml-tools.nbm"
downloadsize="41364"
homepage="http://www.netbeans.org/"
license="4AC3D4C1" moduleauthor=""
needsrestart="false"
releasedate="2019/07/16" targetcluster="ide">
<manifest AutoUpdate-Show-In-Client="false"
OpenIDE-Module="org.netbeans.modules.xml.tools/2"
OpenIDE-Module-Display-Category="XML"
OpenIDE-Module-Implementation-Version="netbeans-release-428-on-20190716"
OpenIDE-Module-Java-Dependencies="Java > 1.7"
OpenIDE-Module-Long-Description="The module contains various actions and tools. Especially action to generate simple DTD from XML document."
OpenIDE-Module-Module-Dependencies="org.netbeans.api.xml/1 > 1.41, org.netbeans.api.xml.ui/1 > 1.41, org.netbeans.modules.xml > 1.2, org.netbeans.modules.xml.core/2 > 1.14, org.netbeans.modules.xml.tax/2 > 1.16, org.openide.awt > 6.2, org.openide.dialogs > 6.2, org.openide.filesystems > 9.0, org.openide.loaders > 7.61, org.openide.nodes > 6.2, org.openide.text > 6.16, org.openide.util.ui > 9.3, org.openide.util > 9.3, org.openide.util.lookup > 8.0"
OpenIDE-Module-Name="XML Productivity Tools"
OpenIDE-Module-Requires="org.openide.modules.ModuleFormat1"
OpenIDE-Module-Short-Description="The module contains various actions and tools."
OpenIDE-Module-Specification-Version="1.48"/>
</module>
<!-- ... --->
But a call like this:
curl --output - https://netbeans-vm.apache.org/uc/11.1/updates.xml.gz?nbmBase=http%3A%2F%2Fmirror.23media.de%2Fapache%2F | gzip -d
would yield
<!-- ... --->
<module codenamebase="org.netbeans.modules.xml.tools"
distribution="http://mirror.23media.de/apache/netbeans/netbeans/11.1/nbms/ide/org-netbeans-modules-xml-tools.nbm"
downloadsize="41364"
homepage="http://www.netbeans.org/"
license="4AC3D4C1" moduleauthor=""
needsrestart="false"
releasedate="2019/07/16" targetcluster="ide">
<manifest AutoUpdate-Show-In-Client="false"
OpenIDE-Module="org.netbeans.modules.xml.tools/2"
OpenIDE-Module-Display-Category="XML"
OpenIDE-Module-Implementation-Version="netbeans-release-428-on-20190716"
OpenIDE-Module-Java-Dependencies="Java > 1.7"
OpenIDE-Module-Long-Description="The module contains various actions and tools. Especially action to generate simple DTD from XML document."
OpenIDE-Module-Module-Dependencies="org.netbeans.api.xml/1 > 1.41, org.netbeans.api.xml.ui/1 > 1.41, org.netbeans.modules.xml > 1.2, org.netbeans.modules.xml.core/2 > 1.14, org.netbeans.modules.xml.tax/2 > 1.16, org.openide.awt > 6.2, org.openide.dialogs > 6.2, org.openide.filesystems > 9.0, org.openide.loaders > 7.61, org.openide.nodes > 6.2, org.openide.text > 6.16, org.openide.util.ui > 9.3, org.openide.util > 9.3, org.openide.util.lookup > 8.0"
OpenIDE-Module-Name="XML Productivity Tools"
OpenIDE-Module-Requires="org.openide.modules.ModuleFormat1"
OpenIDE-Module-Short-Description="The module contains various actions and tools."
OpenIDE-Module-Specification-Version="1.48"/>
</module>
<!-- ... --->
So affected users could modify their plugin centers to use a fixed
mirror and could get that whitelisted.
That would need some documentation on the download page, but that way
normal users are not affected, core apache infrastructure is not
affected and enterprise users still can work.
How does this sound?
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Update centers based on mirrors are a nightmare to support in an
enterprise environment
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 5 Feb 2020, 14:21 Peter Kovacs, <Pe...@apache.org> wrote:
> The ASF publishes the releases at:
>
> https://apache.org/dist/netbeans/
>
> Maybe that is less of an issue?
>
That's an option, keeping in mind the limits here if there's a lot of
corporate use though - https://www.apache.org/dev/infra-ban.html
Otherwise maybe local mirroring?
Best wishes,
Neil
>
Re: Update centers based on mirrors are a nightmare to support in an
enterprise environment
Posted by Peter Kovacs <Pe...@Apache.org>.
The ASF publishes the releases at:
https://apache.org/dist/netbeans/
Maybe that is less of an issue?
On 05.02.20 14:50, Geertjan Wielenga wrote:
> I'm not sure what the solution is.
>
> Gj
>
> On Wed, Feb 5, 2020 at 2:46 PM Jean-Marc Borer <jm...@gmail.com> wrote:
>
>> Any opinion here?
>>
>> For us, mirrors are just giving us headaches for plugins and updates...
>>
>> On Thu, Jan 30, 2020 at 2:55 PM Jean-Marc Borer <jm...@gmail.com> wrote:
>>
>>> Hi guys,
>>>
>>> This is bit of a complaint addressed to the NB infra community. When you
>>> are stuck behind corporate proxy that is very aggressively filtering web
>>> content, mirrors are a nightmare for you. In my case we need to whitelist
>>> every single server hosting java binaries otherwise we get empty files.
>> As
>>> such, it is not viable to declare every single mirror (the company won't
>>> accept that).
>>>
>>> So my request is: please for NB IDE updates and their core components,
>>> never ever use mirrors or provide an option to always point to the same
>>> mirrored site.
>>>
>>> This may sound silly, but is really an issue within enterprises and
>>> therefore prevent the adoption of NB IDE far more than the alternatives,
>>> which is really a pity...
>>>
>>> Regards,
>>>
>>> JMB
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Update centers based on mirrors are a nightmare to support in an
enterprise environment
Posted by Jean-Marc Borer <jm...@gmail.com>.
I like Matthias idea. At least with companies with very restrictive
whitelisting policies, you could force the use of a whitelisted mirror.
Sounds good.
Is there a need to write a plugin for that, or change something on the
infra or is it an improvement request for NB?
Cheers,
JMB
On Thu, Feb 6, 2020 at 8:22 AM Andreas Sewe <se...@cqse.eu> wrote:
> Geertjan Wielenga wrote:
> > I'm not sure what the solution is.
>
> FYI, the Eclipse Installer (aka Eclipse Oomph) has a "Use mirrors" check
> box, which is checked by default and thus likely being using in the vast
> majority of installs. The traditional Eclipse "Install New Software
> Dialog" doesn't expose such an option, though.
>
> Best wishes,
>
> Andreas
>
> --
> Dr. Andreas Sewe | sewe@cqse.eu | +49 152 56342856
> CQSE GmbH | Centa-Hafenbraedl-Strasse 59 | 81249 Muenchen | www.cqse.eu
> Amtsgericht Muenchen | HRB 177678 | GF: F. Deissenboeck, M. Feilkas
>
>
Re: Update centers based on mirrors are a nightmare to support in an
enterprise environment
Posted by Andreas Sewe <se...@cqse.eu>.
Geertjan Wielenga wrote:
> I'm not sure what the solution is.
FYI, the Eclipse Installer (aka Eclipse Oomph) has a "Use mirrors" check
box, which is checked by default and thus likely being using in the vast
majority of installs. The traditional Eclipse "Install New Software
Dialog" doesn't expose such an option, though.
Best wishes,
Andreas
--
Dr. Andreas Sewe | sewe@cqse.eu | +49 152 56342856
CQSE GmbH | Centa-Hafenbraedl-Strasse 59 | 81249 Muenchen | www.cqse.eu
Amtsgericht Muenchen | HRB 177678 | GF: F. Deissenboeck, M. Feilkas
Re: Update centers based on mirrors are a nightmare to support in an
enterprise environment
Posted by Geertjan Wielenga <ge...@apache.org>.
I'm not sure what the solution is.
Gj
On Wed, Feb 5, 2020 at 2:46 PM Jean-Marc Borer <jm...@gmail.com> wrote:
> Any opinion here?
>
> For us, mirrors are just giving us headaches for plugins and updates...
>
> On Thu, Jan 30, 2020 at 2:55 PM Jean-Marc Borer <jm...@gmail.com> wrote:
>
> > Hi guys,
> >
> > This is bit of a complaint addressed to the NB infra community. When you
> > are stuck behind corporate proxy that is very aggressively filtering web
> > content, mirrors are a nightmare for you. In my case we need to whitelist
> > every single server hosting java binaries otherwise we get empty files.
> As
> > such, it is not viable to declare every single mirror (the company won't
> > accept that).
> >
> > So my request is: please for NB IDE updates and their core components,
> > never ever use mirrors or provide an option to always point to the same
> > mirrored site.
> >
> > This may sound silly, but is really an issue within enterprises and
> > therefore prevent the adoption of NB IDE far more than the alternatives,
> > which is really a pity...
> >
> > Regards,
> >
> > JMB
> >
>