You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by janI <ja...@apache.org> on 2013/06/02 16:43:44 UTC
updates.openoffice.org
Hi.
I have asked by my infra collegaues, to ensuere we (AOO) have consensus on
how to handle updates.openoffice.org
I nobody objects I will assume lazy consensus in 72 hours from now and
1) create trunk/ooo-site/upates
2) let https://updates.openoffice.org point to trunk/ooo-site/update
rgds
jan i.
Re: updates.openoffice.org
Posted by Kay Schenk <ka...@gmail.com>.
On Sun, Jun 2, 2013 at 7:43 AM, janI <ja...@apache.org> wrote:
> Hi.
>
> I have asked by my infra collegaues, to ensuere we (AOO) have consensus on
> how to handle updates.openoffice.org
>
> I nobody objects I will assume lazy consensus in 72 hours from now and
>
> 1) create trunk/ooo-site/upates
> 2) let https://updates.openoffice.org point to trunk/ooo-site/update
>
> rgds
> jan i.
>
Is this an old URL for actual program updates?
If so, I think it should be going to:
http://www.openoffice.org/projects/update/
Hopefully someone else will weight in here.
--
----------------------------------------------------------------------------------------
MzK
"You can't believe one thing and do another.
What you believe and what you do are the same thing."
-- Leonard Peltier
Re: updates.openoffice.org
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Jun 3, 2013 at 5:11 AM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:
> Hi,
>
>
> On 03.06.2013 13:50, janI wrote:
>
>> On 3 June 2013 11:43, Oliver-Rainer Wittmann <or...@googlemail.com>*
>> *wrote:
>>
>> Hi,
>>>
>>> On 02.06.2013 16:43, janI wrote:
>>>
>>> Hi.
>>>>
>>>> I have asked by my infra collegaues, to ensuere we (AOO) have consensus
>>>> on
>>>> how to handle updates.openoffice.org
>>>>
>>>> I nobody objects I will assume lazy consensus in 72 hours from now and
>>>>
>>>> 1) create trunk/ooo-site/upates
>>>>
>>>>
>>> My understandings of the communication with infra is that
>>> ^/openoffice/updates-site/****trunk/
>>> should be created for holding the needed application update data for AOO
>>> 4.0 and later.
>>>
>>> I am not sure, if my understanding is correct.
>>> Thus, please let us clarify it.
>>>
>>>
>>> Just for your information - the locations for the released versions are:
>>> - ^/openoffice/ooo-site/trunk/****content/projects/update/****aoo341/
>>> used by
>>> UpdateURL http://www.openoffice.org/****projects/update/aoo341/check.***
>>> * <http://www.openoffice.org/**projects/update/aoo341/check.**>
>>> Update <http://www.openoffice.org/**projects/update/aoo341/check.**
>>> Update <http://www.openoffice.org/projects/update/aoo341/check.Update>>for
>>> AOO 3.4.1
>>> - ^/openoffice/ooo-site/trunk/****content/projects/update38/ used by
>>> UpdateURL http://update38.services.**ope**noffice.org/**<http://openoffice.org/**>
>>> ProductUpdateService/check.****Update<http://update38.**
>>> services.openoffice.org/**ProductUpdateService/check.**Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>>for
>>> AOO 3.4
>>> - ^/openoffice/ooo-site/trunk/****content/projects/update36/ used by
>>> UpdateURL http://update36.services.**ope**noffice.org/**<http://openoffice.org/**>
>>> ProductUpdateService/check.****Update<http://update36.**
>>> services.openoffice.org/**ProductUpdateService/check.**Update<http://update36.services.openoffice.org/ProductUpdateService/check.Update>>for
>>> OOo 3.3
>>> - ^/openoffice/ooo-site/trunk/****content/projects/update35/ used by
>>> UpdateURL http://update35.services.**ope**noffice.org/**<http://openoffice.org/**>
>>> ProductUpdateService/check.****Update<http://update35.**
>>> services.openoffice.org/**ProductUpdateService/check.**Update<http://update35.services.openoffice.org/ProductUpdateService/check.Update>>for
>>> OOo 3.2.1
>>> - ^/openoffice/ooo-site/trunk/****content/projects/update34/ used by
>>> UpdateURL http://update34.services.**ope**noffice.org/**<http://openoffice.org/**>
>>> ProductUpdateService/check.****Update<http://update34.**
>>> services.openoffice.org/**ProductUpdateService/check.**Update<http://update34.services.openoffice.org/ProductUpdateService/check.Update>>for
>>> OOo 3.2
>>>
>>>
>> Using that we should make
>> ^/openoffice/ooo-site/trunk/**content/projects/update40/
>> and have updates.o.o point at that.
>>
>
> We have already ^/openoffice/ooo-site/trunk/**content/projects/aoo40/ for
> current AOO 4.0 trunk builds - as stated in the communication with infra.
>
> I am currently very confused.
> Infra is telling "create ^/openoffice/updates-site/**trunk/"
> Jan is proposing "^/openoffice/trunk/ooo-site/**upates/"
> We already have "^/openoffice/ooo-site/trunk/**content/projects/aoo40/"
>
> If we can use whatever location for URL https://updates.openoffice.**org/<https://updates.openoffice.org/>,
> why does we had a discussion on a new location?
Would this work if: https://updates.openoffice.org/
was directed to, and certificate applies to:
/openoffice/ooo-site/trunk/content/projects/
We still need to maintain the viability of the other update areas, don't we?
and, I think we originally had:
http://updates.services.openoffice.org
This caused problems long ago when we did a re-route of it. I'm not sure if
it still would or not.
@Oliver -- I'm not sure what you did to get some of this working.
>
>
>> Changing updates.o.o to point at something else is a one line statement so
>> no problem.
>>
>> Would it not be better if the AOO executable always called
>> https://updates.openoffice.**org?version=x<https://updates.openoffice.org?version=x>
>>
>> That way the executable stays stable over versions, and we can have 1
>> server side script that checks the version.
>>
>>
> May be it would be better.
> But, somebody would be needed to implement such an adaption in the
> OpenOffice code and to implement the server side script.
>
> Best regards, Oliver.
>
>
> rgds
>> jan I
>>
>> and have
>>
>>
>>
>>>
>>>
>>> 2) let https://updates.openoffice.org point to trunk/ooo-site/update
>>>
>>>>
>>>>
>>> Yes, https://updates.openoffice.org should point to the new application
>>> update data location.
>>>
>>>
>>> Best regards, Oliver.
>>>
>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**pache.org<http://apache.org>
>>> <de...@openoffice.apache.org>
>>> >
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------------------------
MzK
"You can't believe one thing and do another.
What you believe and what you do are the same thing."
-- Leonard Peltier
Re: updates.openoffice.org
Posted by Rob Weir <ro...@apache.org>.
On Wed, Jun 5, 2013 at 11:50 AM, janI <ja...@apache.org> wrote:
> On 5 June 2013 17:43, Rob Weir <ro...@apache.org> wrote:
>
>> On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
>> > On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
>> >
>> >> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
>> >> > On 5 June 2013 11:05, Oliver-Rainer Wittmann <
>> orwittmann@googlemail.com
>> >> >wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> sorry for top-posting, but I think it makes sense to clean up some
>> >> things.
>> >> >>
>> >> >> Some facts and my opinions:
>> >> >> (1)
>> >> >> Fact: In communication with infra, infra had proposed
>> >> >> https://updates.openoffice.**org/ <https://updates.openoffice.org/>
>> (
>> >> >> https://ooo-updates.**openoffice.org/<
>> >> https://ooo-updates.openoffice.org/>as the backup) as the URL for the
>> >> resources accessed by the update
>> >> >> functionality by AOO 4.0 and later. Nobody objects.
>> >> >> My opinion: I think we should go for it.
>> >> >>
>> >> > +1, I will check dns, add whats missing, and when the cert arrives
>> update
>> >> > erebus-ssl (the https: proxy)
>> >> >
>> >> >>
>> >> >> (2)
>> >> >> Fact: In communication with infra, infra had proposed
>> >> >> ^/openoffice/updates-site/**trunk as the SVN location for the
>> resources
>> >> >> needed for the update functionality by AOO 4.0 and later.
>> >> >> My opinion: I believe it would be good to have the update resources
>> >> >> separated from the website resources. It would mean to move
>> >> >> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update
>> to
>> >> >> ^/openoffice/updates-site/**trunk/aoo40/check.Update
>> >> >>
>> >> > +1 No problem, I can create the path in svn and add an alias (link) in
>> >> the
>> >> > httpd server. Btw this is easy to change later, it is a simple one
>> line,
>> >> in
>> >> > the configuration.
>> >> >
>> >> >
>> >> >>
>> >> >> (3)
>> >> >> My understanding: I think infra had in mind to "map"
>> >> >> https://updates.openoffice.org (resp. https://ooo-updates.**
>> >> >> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
>> >> >> ^/openoffice/updates-site/**trunk
>> >> >> Please correct me, if my understanding is not correct.
>> >> >>
>> >> > it was correct, but changed to (2)
>> >> >
>> >> >>
>> >> >> (4)
>> >> >> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo 3.2.1
>> >> and
>> >> >> OOo 3.2 will remain at their current SVN location and will be
>> accessed
>> >> by
>> >> >> the current UpdateURLs.
>> >> >> My opinion: Thus, I believe there will be no change to the SVN
>> >> locations,
>> >> >> to the URLs and to the "URL mapping/forwarding" (sorry, I do not know
>> >> the
>> >> >> correct term here) for the update resources used by already released
>> >> >> versions.
>> >> >>
>> >> > mapping is the correct term. There will be no changes apart from (1)
>> and
>> >> > (2)
>> >> >
>> >> >>
>> >> >>
>> >> >> My proposal:
>> >> >> I propose to follow infra's proposal mentioned above in (1) and (2).
>> >> >>
>> >> > I have added it to infra tasks. We are currently waiting for the cert
>> to
>> >> be
>> >> > sent, then the first step will be to get https: working for wiki and
>> >> > forums, second step is updates.o.o
>> >> >
>> >> >>
>> >> >>
>> >> >> Best regards, Oliver.
>> >> >
>> >> > thx for a very clear mail, if nobody objects within the next 72
>> hours,
>> >> it
>> >> > will be implemented as you propose.
>> >> >
>> >>
>> >> An extra step will be needed. Presumably we want the Apache CMS
>> >> enabled so it publishes files from the SVN dir to the website dir.
>> >> This doesn't happen automatically.
>> >>
>> >
>> > that is not only an extra step, that can turn out to be a bigger
>> challenge.
>> > Having CMS enabled
>> > is a very valid request, but then please choose a location inside the
>> > web-site where CMS is already enabled.
>> >
>>
>> We already have two separate CMS publish targets from our SVN: /site
>> (openoffice.apache.org) and /ooo-site (www.openoffice.org). Having a
>> third one should not be a problem. I'd like to avoid the complexity
>> that would occur if we had the same SVN dir connected to two different
>> CMS targets.
>>
>
> of course it can be done its software, its just more work and more admin
> afterward.
>
> You would not have one svn dir connected to two different cms targets if
> target dir is inside www.openoffice.org (which is what I suggested).
>
> updates.openoffice.org is logically just a pointer, and would normally
> point inside the www domain (that is the simple solution), but can point
> outside the www domain (which requires changes to httpd.conf, and an extra
> cms setup).
>
However you prefer it is fine with me. This is invisible to the user
and just needs to work, and work before we release AOO 4.0.
-Rob
> rgds
> jan I.
>
>
>>
>> -Rob
>>
>>
>> > rgds
>> > jan i.
>> >
>> >>
>> >> -Rob
>> >>
>> >>
>> >> > rgds
>> >> > jan I.
>> >> >
>> >> >
>> >> >>
>> >> >> On 05.06.2013 00:22, janI wrote:
>> >> >>
>> >> >>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
>> >> >>>
>> >> >>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
>> >> >>>>
>> >> >>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org>
>> wrote:
>> >> >>>>>
>> >> >>>>> On 03/06/2013 Rob Weir wrote:
>> >> >>>>>>
>> >> >>>>>> I think the concern is this:
>> >> >>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
>> >> >>>>>>>
>> >> >>>>>> http://update.openoffice.org> is not HTTPS.
>> >> >>>>
>> >> >>>>>
>> >> >>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
>> >> http://apache.org>
>> >> >>>>>>> <
>> >> >>>>>>>
>> >> >>>>>> https://ooo-site.openoffice.**apache.org<
>> >> https://ooo-site.openoffice.apache.org>>
>> >> >>>> supports SSL, but is
>> >> >>>>
>> >> >>>>> not considered "long term stable". The URL is an artifact of the
>> CMS
>> >> >>>>>>> 3) We're looking for a stable URL. One could be
>> >> >>>>>>> https://updates.openoffice.org****, but that requires an SSL
>> cert
>> >> for
>> >> >>>>>>> *.openoffice.org. But will that be supported in time for the
>> AOO
>> >> 4.0
>> >> >>>>>>> release?
>> >> >>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could be
>> >> >>>>>>> supported via SSL today, using the *.apache.org cert. If we do
>> >> that
>> >> >>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be
>> >> updated
>> >> >>>>>>> and published via the CMS.
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> This is mostly correct, except the fact (in #2 and #4) that the
>> >> current
>> >> >>>>>> certificates only support x.apache.org and not x.y.apache.org:
>> so
>> >> >>>>>> https://ooo-site.apache.org is what is in the sources right now
>> >> (well,
>> >> >>>>>> the last time I checked) and https://openoffice-updates.**a**
>> >> pache.org<http://apache.org>
>> >> >>>>>> <
>> >> >>>>>>
>> >> >>>>> https://openoffice-updates.**apache.org<
>> >> https://openoffice-updates.apache.org>>(or
>> >> >>>> something like that) should be
>> >> >>>> used for the backup plan in #4.
>> >> >>>>
>> >> >>>>>
>> >> >>>>>>
>> >> >>>>> Hi
>> >> >>>>>
>> >> >>>>> I am confused, it seem we nearly all agree on
>> >> >>>>> https://updates.openoffice.**orgbut <
>> >> https://updates.openoffice.orgbut>not on the directory.
>> >> >>>>>
>> >> >>>>> The order for the cert is being processed, when the cert arrives
>> it
>> >> >>>>> needs
>> >> >>>>> to be implemented on erebus-sll (our https: proxy), and we (infra)
>> >> need
>> >> >>>>>
>> >> >>>> to
>> >> >>>>
>> >> >>>>> do some updates on the aoo servers.
>> >> >>>>>
>> >> >>>>> In order to do this work, I need:
>> >> >>>>>
>> >> >>>>> 1) which url (e.g. https://updates.openoffice.org**)
>> >> >>>>> 2) should relate to which directory in svn.
>> >> >>>>>
>> >> >>>>> The last mails contains different proposal ranging from dont do it
>> >> for
>> >> >>>>>
>> >> >>>> 4.0
>> >> >>>>
>> >> >>>>> to different dirs, that is something I cannot implement.
>> >> >>>>>
>> >> >>>>> We can also decide to forget it for https:updates.*, but I need a
>> >> single
>> >> >>>>> decision to be able to implement it.
>> >> >>>>>
>> >> >>>>>
>> >> >>>> Is the cert already here? Or do we have a few weeks to decide?
>> I'd
>> >> >>>> say, don't let this decision get in the way of deploying the cert
>> and
>> >> >>>> enabling it for the website, wikis, forums, etc. The update site
>> >> >>>> doesn't need to be enabled until shortly before AOO 4.0 is
>> released.
>> >> >>>>
>> >> >>>> We have been promised a free cert, I just checked it is not yet in
>> >> our
>> >> >>> hands.
>> >> >>>
>> >> >>> Wiki and other services with login, will be changed to https: to
>> >> adhere to
>> >> >>> asf/infra policy.
>> >> >>> This will be done on infra initative, and the actual setup will be
>> like
>> >> >>> other servers in asf.
>> >> >>>
>> >> >>> update.o.o can come later, but it will definitively save work if we
>> do
>> >> it
>> >> >>> as one task. Of course if
>> >> >>> the decision is to postpone after 4.0, it will be 2 tasks.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>> And depending on when the cert arrives, we might not use it at all
>> for
>> >> >>>> 4.0 updates. If it comes too late we'll just use an apache.org
>> >> >>>> address. So we're really waiting for Infra on this, not the other
>> >> >>>> way around. We need an estimate for when the cert will be
>> purchased
>> >> >>>> so we can decide whether or not it will be used for 4.0 updates.
>> >> >>>>
>> >> >>>>
>> >> >>> As I understand it from the code, the end-user never sees this url,
>> so
>> >> why
>> >> >>> not stick with apache.org ?
>> >> >>>
>> >> >>> rgds
>> >> >>> jan I.
>> >> >>>
>> >> >>>
>> >> >>>> -Rob
>> >> >>>>
>> >> >>>>
>> >> >>>> rgds
>> >> >>>>> jan I.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> Regards,
>> >> >>>>>> Andrea.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> ------------------------------****----------------------------**
>> >> >>>> --**---------
>> >> >>>>
>> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**pache.org
>> <
>> >> http://apache.org>
>> >> >>>>>> <
>> >> >>>>>>
>> >> >>>>> dev-unsubscribe@openoffice.**apache.org<
>> >> dev-unsubscribe@openoffice.apache.org>
>> >> >>>> >
>> >> >>>>
>> >> >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>> ------------------------------**------------------------------**
>> >> >>>> ---------
>> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> >> dev-unsubscribe@openoffice.apache.org>
>> >> >>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>
>> >>
>> ------------------------------**------------------------------**---------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> >> dev-unsubscribe@openoffice.apache.org>
>> >> >> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> >> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 15.06.2013 16:13, janI wrote:
> On 13 June 2013 09:58, Oliver-Rainer Wittmann <or...@googlemail.com>wrote:
>
>> Hi,
>>
>>
>> On 11.06.2013 18:21, janI wrote:
>>
>>> Hi
>>>
>>> I have now filed an issue:
>>>
>>> https://issues.apache.org/**jira/browse/INFRA-6378<https://issues.apache.org/jira/browse/INFRA-6378>
>>>
>>> I will follow up on it (actually already done on #asfinfra)
>>>
>>> Good news is that the cert was just reported to be in our hands. It still
>>> needs to be deployed and work with our setup.
>>>
>>>
>> Thanks for driving this forward.
>>
>>
> http://ooo-updates.apache.org <https://ooo-updates.apache.org>
> https://ooo-updates.apache.org now works correctly
Ok, then I will change the AOO 4.0 Update URL to
https://ooo-updates.apache.org/...
I will also move the corresponding XML file accessed by the update
functionality to the new location.
Best regards, Oliver.
> but
> http://updates.openoffice.org/ <https://updates.openoffice.org/>
> https://updates.openoffice.org/ gives a 404, it seems still to be pointing
> at ^/openoffice/projects/updates
>
> I have commented the jira ticket, and will check on infra that this is also
> made.
>
> rgds
> jan I.
>
> ps. I have added test.html, this can be deleted when someone put correct
> content in the directory.
>
>
>
>
>>
>> Best regards, Oliver.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 13 June 2013 09:58, Oliver-Rainer Wittmann <or...@googlemail.com>wrote:
> Hi,
>
>
> On 11.06.2013 18:21, janI wrote:
>
>> Hi
>>
>> I have now filed an issue:
>>
>> https://issues.apache.org/**jira/browse/INFRA-6378<https://issues.apache.org/jira/browse/INFRA-6378>
>>
>> I will follow up on it (actually already done on #asfinfra)
>>
>> Good news is that the cert was just reported to be in our hands. It still
>> needs to be deployed and work with our setup.
>>
>>
> Thanks for driving this forward.
>
>
http://ooo-updates.apache.org <https://ooo-updates.apache.org>
https://ooo-updates.apache.org now works correctly
but
http://updates.openoffice.org/ <https://updates.openoffice.org/>
https://updates.openoffice.org/ gives a 404, it seems still to be pointing
at ^/openoffice/projects/updates
I have commented the jira ticket, and will check on infra that this is also
made.
rgds
jan I.
ps. I have added test.html, this can be deleted when someone put correct
content in the directory.
>
> Best regards, Oliver.
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: updates.openoffice.org
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 11.06.2013 18:21, janI wrote:
> Hi
>
> I have now filed an issue:
>
> https://issues.apache.org/jira/browse/INFRA-6378
>
> I will follow up on it (actually already done on #asfinfra)
>
> Good news is that the cert was just reported to be in our hands. It still
> needs to be deployed and work with our setup.
>
Thanks for driving this forward.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
Hi
I have now filed an issue:
https://issues.apache.org/jira/browse/INFRA-6378
I will follow up on it (actually already done on #asfinfra)
Good news is that the cert was just reported to be in our hands. It still
needs to be deployed and work with our setup.
rgds
jan I.
On 11 June 2013 13:47, Oliver-Rainer Wittmann <or...@googlemail.com>wrote:
> Hi,
>
>
> On 11.06.2013 13:29, Rob Weir wrote:
>
>> On Tue, Jun 11, 2013 at 7:08 AM, Oliver-Rainer Wittmann
>> <or...@googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> On 11.06.2013 12:55, janI wrote:
>>>
>>>>
>>>> On 6 June 2013 18:33, Kay Schenk <ka...@gmail.com> wrote:
>>>>
>>>> [snip]
>>>>
>>>>
>>>>
>>>> It seems I was too fast (or more correctly too slow), at least the
>>>> agrement
>>>> disapeared, and I have been asked to file a jira, for this part of the
>>>> https upgrade, and specifically not for the cert part (which is the
>>>> overall
>>>> task, covering both this and other issues).
>>>>
>>>> if we do it now with http, I can foresee the same thing happening with
>>>> the
>>>> https transfer, so I will highly recommend (as discussed earlier) that
>>>> we
>>>> forget updates for 4.0 and do it for 4.1 when the cert is installed.
>>>>
>>>> Of course if the community, want me to file a jira, and try to get it
>>>> done
>>>> for 4.0, I will do it.
>>>>
>>>> The cert is delayed, because of no response from the sponsor. There is
>>>> at
>>>> the moment a request to buy it instead. There are no jira detailing this
>>>> issue, just some irc communication.
>>>>
>>>>
>>> Thanks for your work and eye-keeping on it.
>>>
>>> Thus, we will not have a cert for openoffice.org in time for the AOO 4.0
>>> release.
>>>
>>> Can we go for the _corrected_ fallback URL
>>> https://ooo-updates.apache.org
>>> for AOO 4.0 or do we have to keep https://ooo-site.apache.org?
>>>
>>> Both would be fine for me, but I heard that https://ooo-site.apache.orgwill
>>> not work for ever.
>>>
>>>
>>
>> Let's get a JIRA issue entered for creating that subdomain. I think
>> Daniel suggested it that subdomain originally. That gives us the
>> required SSL support for 4.0.
>>
>>
> +1
>
>
> Best regards, Oliver.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: updates.openoffice.org
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 11.06.2013 13:29, Rob Weir wrote:
> On Tue, Jun 11, 2013 at 7:08 AM, Oliver-Rainer Wittmann
> <or...@googlemail.com> wrote:
>> Hi,
>>
>> On 11.06.2013 12:55, janI wrote:
>>>
>>> On 6 June 2013 18:33, Kay Schenk <ka...@gmail.com> wrote:
>>>
>>> [snip]
>>>
>>>
>>>
>>> It seems I was too fast (or more correctly too slow), at least the
>>> agrement
>>> disapeared, and I have been asked to file a jira, for this part of the
>>> https upgrade, and specifically not for the cert part (which is the
>>> overall
>>> task, covering both this and other issues).
>>>
>>> if we do it now with http, I can foresee the same thing happening with the
>>> https transfer, so I will highly recommend (as discussed earlier) that we
>>> forget updates for 4.0 and do it for 4.1 when the cert is installed.
>>>
>>> Of course if the community, want me to file a jira, and try to get it done
>>> for 4.0, I will do it.
>>>
>>> The cert is delayed, because of no response from the sponsor. There is at
>>> the moment a request to buy it instead. There are no jira detailing this
>>> issue, just some irc communication.
>>>
>>
>> Thanks for your work and eye-keeping on it.
>>
>> Thus, we will not have a cert for openoffice.org in time for the AOO 4.0
>> release.
>>
>> Can we go for the _corrected_ fallback URL https://ooo-updates.apache.org
>> for AOO 4.0 or do we have to keep https://ooo-site.apache.org?
>>
>> Both would be fine for me, but I heard that https://ooo-site.apache.org will
>> not work for ever.
>>
>
>
> Let's get a JIRA issue entered for creating that subdomain. I think
> Daniel suggested it that subdomain originally. That gives us the
> required SSL support for 4.0.
>
+1
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jun 11, 2013 at 7:08 AM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi,
>
>
> On 11.06.2013 12:55, janI wrote:
>>
>> On 6 June 2013 18:33, Kay Schenk <ka...@gmail.com> wrote:
>>
>> [snip]
>>
>>
>>
>> It seems I was too fast (or more correctly too slow), at least the
>> agrement
>> disapeared, and I have been asked to file a jira, for this part of the
>> https upgrade, and specifically not for the cert part (which is the
>> overall
>> task, covering both this and other issues).
>>
>> if we do it now with http, I can foresee the same thing happening with the
>> https transfer, so I will highly recommend (as discussed earlier) that we
>> forget updates for 4.0 and do it for 4.1 when the cert is installed.
>>
>> Of course if the community, want me to file a jira, and try to get it done
>> for 4.0, I will do it.
>>
>> The cert is delayed, because of no response from the sponsor. There is at
>> the moment a request to buy it instead. There are no jira detailing this
>> issue, just some irc communication.
>>
>
> Thanks for your work and eye-keeping on it.
>
> Thus, we will not have a cert for openoffice.org in time for the AOO 4.0
> release.
>
> Can we go for the _corrected_ fallback URL https://ooo-updates.apache.org
> for AOO 4.0 or do we have to keep https://ooo-site.apache.org?
>
> Both would be fine for me, but I heard that https://ooo-site.apache.org will
> not work for ever.
>
Let's get a JIRA issue entered for creating that subdomain. I think
Daniel suggested it that subdomain originally. That gives us the
required SSL support for 4.0.
-Rob
>
> Best regards, Oliver.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 11.06.2013 12:55, janI wrote:
> On 6 June 2013 18:33, Kay Schenk <ka...@gmail.com> wrote:
>
>[snip]
>
>
> It seems I was too fast (or more correctly too slow), at least the agrement
> disapeared, and I have been asked to file a jira, for this part of the
> https upgrade, and specifically not for the cert part (which is the overall
> task, covering both this and other issues).
>
> if we do it now with http, I can foresee the same thing happening with the
> https transfer, so I will highly recommend (as discussed earlier) that we
> forget updates for 4.0 and do it for 4.1 when the cert is installed.
>
> Of course if the community, want me to file a jira, and try to get it done
> for 4.0, I will do it.
>
> The cert is delayed, because of no response from the sponsor. There is at
> the moment a request to buy it instead. There are no jira detailing this
> issue, just some irc communication.
>
Thanks for your work and eye-keeping on it.
Thus, we will not have a cert for openoffice.org in time for the AOO 4.0
release.
Can we go for the _corrected_ fallback URL
https://ooo-updates.apache.org for AOO 4.0 or do we have to keep
https://ooo-site.apache.org?
Both would be fine for me, but I heard that https://ooo-site.apache.org
will not work for ever.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 6 June 2013 18:33, Kay Schenk <ka...@gmail.com> wrote:
> On Thu, Jun 6, 2013 at 12:54 AM, janI <ja...@apache.org> wrote:
>
> > On 6 June 2013 04:15, Dave Fisher <wa...@apache.org> wrote:
> >
> > >
> > > On Jun 5, 2013, at 12:37 PM, Kay Schenk <ka...@gmail.com> wrote:
> > >
> > > > On Wed, Jun 5, 2013 at 8:50 AM, janI <ja...@apache.org> wrote:
> > > >
> > > >> On 5 June 2013 17:43, Rob Weir <ro...@apache.org> wrote:
> > > >>
> > > >>> On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
> > > >>>> On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
> > > >>>>
> > > >>>>> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
> > > >>>>>> On 5 June 2013 11:05, Oliver-Rainer Wittmann <
> > > >>> orwittmann@googlemail.com
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Hi,
> > > >>>>>>>
> > > >>>>>>> sorry for top-posting, but I think it makes sense to clean up
> > some
> > > >>>>> things.
> > > >>>>>>>
> > > >>>>>>> Some facts and my opinions:
> > > >>>>>>> (1)
> > > >>>>>>> Fact: In communication with infra, infra had proposed
> > > >>>>>>> https://updates.openoffice.**org/ <
> > https://updates.openoffice.org/
> > > >>>
> > > >>> (
> > > >>>>>>> https://ooo-updates.**openoffice.org/<
> > > >>>>> https://ooo-updates.openoffice.org/>as the backup) as the URL
> for
> > > the
> > > >>>>> resources accessed by the update
> > > >>>>>>> functionality by AOO 4.0 and later. Nobody objects.
> > > >>>>>>> My opinion: I think we should go for it.
> > > >>>>>> +1, I will check dns, add whats missing, and when the cert
> arrives
> > > >>> update
> > > >>>>>> erebus-ssl (the https: proxy)
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> (2)
> > > >>>>>>> Fact: In communication with infra, infra had proposed
> > > >>>>>>> ^/openoffice/updates-site/**trunk as the SVN location for the
> > > >>> resources
> > > >>>>>>> needed for the update functionality by AOO 4.0 and later.
> > > >>>>>>> My opinion: I believe it would be good to have the update
> > resources
> > > >>>>>>> separated from the website resources. It would mean to move
> > > >>>>>>>
> > ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update
> > > >>> to
> > > >>>>>>> ^/openoffice/updates-site/**trunk/aoo40/check.Update
> > > >>>>>> +1 No problem, I can create the path in svn and add an alias
> > (link)
> > > >> in
> > > >>>>> the
> > > >>>>>> httpd server. Btw this is easy to change later, it is a simple
> one
> > > >>> line,
> > > >>>>> in
> > > >>>>>> the configuration.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> (3)
> > > >>>>>>> My understanding: I think infra had in mind to "map"
> > > >>>>>>> https://updates.openoffice.org (resp. https://ooo-updates.**
> > > >>>>>>> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
> > > >>>>>>> ^/openoffice/updates-site/**trunk
> > > >>>>>>> Please correct me, if my understanding is not correct.
> > > >>>>>> it was correct, but changed to (2)
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> (4)
> > > >>>>>>> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo
> > > >> 3.2.1
> > > >>>>> and
> > > >>>>>>> OOo 3.2 will remain at their current SVN location and will be
> > > >>> accessed
> > > >>>>> by
> > > >>>>>>> the current UpdateURLs.
> > > >>>>>>> My opinion: Thus, I believe there will be no change to the SVN
> > > >>>>> locations,
> > > >>>>>>> to the URLs and to the "URL mapping/forwarding" (sorry, I do
> not
> > > >> know
> > > >>>>> the
> > > >>>>>>> correct term here) for the update resources used by already
> > > >> released
> > > >>>>>>> versions.
> > > >>>>>> mapping is the correct term. There will be no changes apart from
> > (1)
> > > >>> and
> > > >>>>>> (2)
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> My proposal:
> > > >>>>>>> I propose to follow infra's proposal mentioned above in (1) and
> > > >> (2).
> > > >>>>>> I have added it to infra tasks. We are currently waiting for the
> > > >> cert
> > > >>> to
> > > >>>>> be
> > > >>>>>> sent, then the first step will be to get https: working for wiki
> > and
> > > >>>>>> forums, second step is updates.o.o
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> Best regards, Oliver.
> > > >>>>>>
> > > >>>>>> thx for a very clear mail, if nobody objects within the next 72
> > > >>> hours,
> > > >>>>> it
> > > >>>>>> will be implemented as you propose.
> > > >>>>>
> > > >>>>> An extra step will be needed. Presumably we want the Apache CMS
> > > >>>>> enabled so it publishes files from the SVN dir to the website
> dir.
> > > >>>>> This doesn't happen automatically.
> > > >>>>
> > > >>>> that is not only an extra step, that can turn out to be a bigger
> > > >>> challenge.
> > > >>>> Having CMS enabled
> > > >>>> is a very valid request, but then please choose a location inside
> > the
> > > >>>> web-site where CMS is already enabled.
> > > >>>
> > > >>> We already have two separate CMS publish targets from our SVN:
> /site
> > > >>> (openoffice.apache.org) and /ooo-site (www.openoffice.org).
> Having
> > a
> > > >>> third one should not be a problem. I'd like to avoid the
> complexity
> > > >>> that would occur if we had the same SVN dir connected to two
> > different
> > > >>> CMS targets.
> > > >>
> > > >> of course it can be done its software, its just more work and more
> > admin
> > > >> afterward.
> > > >>
> > > >> You would not have one svn dir connected to two different cms
> targets
> > if
> > > >> target dir is inside www.openoffice.org (which is what I
> suggested).
> > > >>
> > > >> updates.openoffice.org is logically just a pointer, and would
> > normally
> > > >> point inside the www domain (that is the simple solution), but can
> > point
> > > >> outside the www domain (which requires changes to httpd.conf, and an
> > > extra
> > > >> cms setup).
> > > >
> > > > from Oliver's commmunication [1], it seems that
> > updates.openoffice.orghas
> > > > been suggested to be *outside* the current web site domain, and
> > followed
> > > by
> > > > his comments --
> > > >
> > > > "My opinion: I believe it would be good to have the update resources
> > > > separated from the website resources. It would mean to move
> > > > ^/openoffice/ooo-site/trunk/content/projects/aoo40/check.Update to
> > > > ^/openoffice/updates-site/trunk/aoo40/check.Update"
> > > >
> > > > I feel we should NOT point the new update to any area within the
> > existing
> > > > www domain (we had some BIG problems initially trying to enable
> updates
> > > > through the web server), so a new CMS would be needed. Hopefully,
> this
> > is
> > > > not a horrendous task.
> > >
> > > Infra will likely svnpubsub the new part of svn that has the update
> logic
> > > as bare files. Projects are not required to use CMS, but are required
> to
> > > use svnpubsub,
> > >
> > correct, that was (and is) the plan.
> >
> > >
> > > I see no reason this needs to be pushed through CMS. None, it's too
> much
> > > extra work.
> > >
> > +1
> >
> > I will get the things done (following oliver's proposal) during the
> > weekend, so we only need to add the cert when it arrives.
> >
> > rgds
> > jan I.
> >
>
> great on all counts...and I see the new area has been established!
>
It seems I was too fast (or more correctly too slow), at least the agrement
disapeared, and I have been asked to file a jira, for this part of the
https upgrade, and specifically not for the cert part (which is the overall
task, covering both this and other issues).
if we do it now with http, I can foresee the same thing happening with the
https transfer, so I will highly recommend (as discussed earlier) that we
forget updates for 4.0 and do it for 4.1 when the cert is installed.
Of course if the community, want me to file a jira, and try to get it done
for 4.0, I will do it.
The cert is delayed, because of no response from the sponsor. There is at
the moment a request to buy it instead. There are no jira detailing this
issue, just some irc communication.
rgds
jan I.
>
>
> >
> > >
> > > Thanks Oliver and Jan.
> > >
> > > Regards,
> > > Dave
> > >
> > >
> > > >
> > > >
> > > >
> > > >> rgds
> > > >> jan I.
> > > >>
> > > >>
> > > >>>
> > > >>> -Rob
> > > >>>
> > > >>>
> > > >>>> rgds
> > > >>>> jan i.
> > > >>>>
> > > >>>>>
> > > >>>>> -Rob
> > > >>>>>
> > > >>>>>
> > > >>>>>> rgds
> > > >>>>>> jan I.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> On 05.06.2013 00:22, janI wrote:
> > > >>>>>>>
> > > >>>>>>>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
> > > >>>>>>>>
> > > >>>>>>>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org>
> > > >>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> On 03/06/2013 Rob Weir wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I think the concern is this:
> > > >>>>>>>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
> > > >>>>>>>>>>> http://update.openoffice.org> is not HTTPS.
> > > >>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
> > > >>>>> http://apache.org>
> > > >>>>>>>>>>>> <
> > > >>>>>>>>>>> https://ooo-site.openoffice.**apache.org<
> > > >>>>> https://ooo-site.openoffice.apache.org>>
> > > >>>>>>>>> supports SSL, but is
> > > >>>>>>>>>
> > > >>>>>>>>>> not considered "long term stable". The URL is an artifact
> of
> > > >> the
> > > >>> CMS
> > > >>>>>>>>>>>> 3) We're looking for a stable URL. One could be
> > > >>>>>>>>>>>> https://updates.openoffice.org****, but that requires an
> > SSL
> > > >>> cert
> > > >>>>> for
> > > >>>>>>>>>>>> *.openoffice.org. But will that be supported in time for
> > the
> > > >>> AOO
> > > >>>>> 4.0
> > > >>>>>>>>>>>> release?
> > > >>>>>>>>>>>> 4) Backup plan is updates.openoffice.apache.org, which
> > could
> > > >> be
> > > >>>>>>>>>>>> supported via SSL today, using the *.apache.org cert. If
> > we
> > > >> do
> > > >>>>> that
> > > >>>>>>>>>>>> we'd want to map that to its own CMS dir in SVN. so it can
> > be
> > > >>>>> updated
> > > >>>>>>>>>>>> and published via the CMS.
> > > >>>>>>>>>>> This is mostly correct, except the fact (in #2 and #4) that
> > the
> > > >>>>> current
> > > >>>>>>>>>>> certificates only support x.apache.org and not
> > x.y.apache.org:
> > > >>> so
> > > >>>>>>>>>>> https://ooo-site.apache.org is what is in the sources
> right
> > > >> now
> > > >>>>> (well,
> > > >>>>>>>>>>> the last time I checked) and https://openoffice-updates.
> > **a**
> > > >>>>> pache.org<http://apache.org>
> > > >>>>>>>>>>> <
> > > >>>>>>>>>> https://openoffice-updates.**apache.org<
> > > >>>>> https://openoffice-updates.apache.org>>(or
> > > >>>>>>>>> something like that) should be
> > > >>>>>>>>> used for the backup plan in #4.
> > > >>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Hi
> > > >>>>>>>>>>
> > > >>>>>>>>>> I am confused, it seem we nearly all agree on
> > > >>>>>>>>>> https://updates.openoffice.**orgbut <
> > > >>>>> https://updates.openoffice.orgbut>not on the directory.
> > > >>>>>>>>>>
> > > >>>>>>>>>> The order for the cert is being processed, when the cert
> > arrives
> > > >>> it
> > > >>>>>>>>>> needs
> > > >>>>>>>>>> to be implemented on erebus-sll (our https: proxy), and we
> > > >> (infra)
> > > >>>>> need
> > > >>>>>>>>> to
> > > >>>>>>>>>
> > > >>>>>>>>>> do some updates on the aoo servers.
> > > >>>>>>>>>>
> > > >>>>>>>>>> In order to do this work, I need:
> > > >>>>>>>>>>
> > > >>>>>>>>>> 1) which url (e.g. https://updates.openoffice.org**)
> > > >>>>>>>>>> 2) should relate to which directory in svn.
> > > >>>>>>>>>>
> > > >>>>>>>>>> The last mails contains different proposal ranging from dont
> > do
> > > >> it
> > > >>>>> for
> > > >>>>>>>>> 4.0
> > > >>>>>>>>>
> > > >>>>>>>>>> to different dirs, that is something I cannot implement.
> > > >>>>>>>>>>
> > > >>>>>>>>>> We can also decide to forget it for https:updates.*, but I
> > need
> > > >> a
> > > >>>>> single
> > > >>>>>>>>>> decision to be able to implement it.
> > > >>>>>>>>> Is the cert already here? Or do we have a few weeks to
> decide?
> > > >>> I'd
> > > >>>>>>>>> say, don't let this decision get in the way of deploying the
> > cert
> > > >>> and
> > > >>>>>>>>> enabling it for the website, wikis, forums, etc. The update
> > > >> site
> > > >>>>>>>>> doesn't need to be enabled until shortly before AOO 4.0 is
> > > >>> released.
> > > >>>>>>>>>
> > > >>>>>>>>> We have been promised a free cert, I just checked it is not
> yet
> > > >> in
> > > >>>>> our
> > > >>>>>>>> hands.
> > > >>>>>>>>
> > > >>>>>>>> Wiki and other services with login, will be changed to https:
> to
> > > >>>>> adhere to
> > > >>>>>>>> asf/infra policy.
> > > >>>>>>>> This will be done on infra initative, and the actual setup
> will
> > be
> > > >>> like
> > > >>>>>>>> other servers in asf.
> > > >>>>>>>>
> > > >>>>>>>> update.o.o can come later, but it will definitively save work
> if
> > > >> we
> > > >>> do
> > > >>>>> it
> > > >>>>>>>> as one task. Of course if
> > > >>>>>>>> the decision is to postpone after 4.0, it will be 2 tasks.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> And depending on when the cert arrives, we might not use it
> at
> > > >> all
> > > >>> for
> > > >>>>>>>>> 4.0 updates. If it comes too late we'll just use an
> > apache.org
> > > >>>>>>>>> address. So we're really waiting for Infra on this, not the
> > > >> other
> > > >>>>>>>>> way around. We need an estimate for when the cert will be
> > > >>> purchased
> > > >>>>>>>>> so we can decide whether or not it will be used for 4.0
> > updates.
> > > >>>>>>>> As I understand it from the code, the end-user never sees this
> > > >> url,
> > > >>> so
> > > >>>>> why
> > > >>>>>>>> not stick with apache.org ?
> > > >>>>>>>>
> > > >>>>>>>> rgds
> > > >>>>>>>> jan I.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> -Rob
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> rgds
> > > >>>>>>>>>> jan I.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Regards,
> > > >>>>>>>>>>> Andrea.
> > > >> ------------------------------****----------------------------**
> > > >>>>>>>>> --**---------
> > > >>>>>>>>>
> > > >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**
> > > >> pache.org
> > > >>> <
> > > >>>>> http://apache.org>
> > > >>>>>>>>>>> <
> > > >>>>>>>>>> dev-unsubscribe@openoffice.**apache.org<
> > > >>>>> dev-unsubscribe@openoffice.apache.org>
> > > >>>>>>>>>
> > > >>>>>>>>>> For additional commands, e-mail:
> > dev-help@openoffice.apache.org
> > > >>>>>>>>>
> > ------------------------------**------------------------------**
> > > >>>>>>>>> ---------
> > > >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**
> > apache.org<
> > > >>>>> dev-unsubscribe@openoffice.apache.org>
> > > >>>>>>>>> For additional commands, e-mail:
> > dev-help@openoffice.apache.org
> > > >>>
> > >
> ------------------------------**------------------------------**---------
> > > >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**
> apache.org<
> > > >>>>> dev-unsubscribe@openoffice.apache.org>
> > > >>>>>>> For additional commands, e-mail:
> dev-help@openoffice.apache.org
> > > >>>>>
> > > >>>>>
> > ---------------------------------------------------------------------
> > > >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > > >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > > >>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > > >>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > > >
> > > >
> > > >
> > > > --
> > > >
> > >
> >
> ----------------------------------------------------------------------------------------
> > > > MzK
> > > >
> > > > "You can't believe one thing and do another.
> > > > What you believe and what you do are the same thing."
> > > > -- Leonard Peltier
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > > For additional commands, e-mail: dev-help@openoffice.apache.org
> > >
> > >
> >
>
>
>
> --
>
> ----------------------------------------------------------------------------------------
> MzK
>
> "You can't believe one thing and do another.
> What you believe and what you do are the same thing."
> -- Leonard Peltier
>
Re: updates.openoffice.org
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Jun 6, 2013 at 12:54 AM, janI <ja...@apache.org> wrote:
> On 6 June 2013 04:15, Dave Fisher <wa...@apache.org> wrote:
>
> >
> > On Jun 5, 2013, at 12:37 PM, Kay Schenk <ka...@gmail.com> wrote:
> >
> > > On Wed, Jun 5, 2013 at 8:50 AM, janI <ja...@apache.org> wrote:
> > >
> > >> On 5 June 2013 17:43, Rob Weir <ro...@apache.org> wrote:
> > >>
> > >>> On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
> > >>>> On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
> > >>>>
> > >>>>> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
> > >>>>>> On 5 June 2013 11:05, Oliver-Rainer Wittmann <
> > >>> orwittmann@googlemail.com
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> sorry for top-posting, but I think it makes sense to clean up
> some
> > >>>>> things.
> > >>>>>>>
> > >>>>>>> Some facts and my opinions:
> > >>>>>>> (1)
> > >>>>>>> Fact: In communication with infra, infra had proposed
> > >>>>>>> https://updates.openoffice.**org/ <
> https://updates.openoffice.org/
> > >>>
> > >>> (
> > >>>>>>> https://ooo-updates.**openoffice.org/<
> > >>>>> https://ooo-updates.openoffice.org/>as the backup) as the URL for
> > the
> > >>>>> resources accessed by the update
> > >>>>>>> functionality by AOO 4.0 and later. Nobody objects.
> > >>>>>>> My opinion: I think we should go for it.
> > >>>>>> +1, I will check dns, add whats missing, and when the cert arrives
> > >>> update
> > >>>>>> erebus-ssl (the https: proxy)
> > >>>>>>
> > >>>>>>>
> > >>>>>>> (2)
> > >>>>>>> Fact: In communication with infra, infra had proposed
> > >>>>>>> ^/openoffice/updates-site/**trunk as the SVN location for the
> > >>> resources
> > >>>>>>> needed for the update functionality by AOO 4.0 and later.
> > >>>>>>> My opinion: I believe it would be good to have the update
> resources
> > >>>>>>> separated from the website resources. It would mean to move
> > >>>>>>>
> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update
> > >>> to
> > >>>>>>> ^/openoffice/updates-site/**trunk/aoo40/check.Update
> > >>>>>> +1 No problem, I can create the path in svn and add an alias
> (link)
> > >> in
> > >>>>> the
> > >>>>>> httpd server. Btw this is easy to change later, it is a simple one
> > >>> line,
> > >>>>> in
> > >>>>>> the configuration.
> > >>>>>>
> > >>>>>>
> > >>>>>>>
> > >>>>>>> (3)
> > >>>>>>> My understanding: I think infra had in mind to "map"
> > >>>>>>> https://updates.openoffice.org (resp. https://ooo-updates.**
> > >>>>>>> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
> > >>>>>>> ^/openoffice/updates-site/**trunk
> > >>>>>>> Please correct me, if my understanding is not correct.
> > >>>>>> it was correct, but changed to (2)
> > >>>>>>
> > >>>>>>>
> > >>>>>>> (4)
> > >>>>>>> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo
> > >> 3.2.1
> > >>>>> and
> > >>>>>>> OOo 3.2 will remain at their current SVN location and will be
> > >>> accessed
> > >>>>> by
> > >>>>>>> the current UpdateURLs.
> > >>>>>>> My opinion: Thus, I believe there will be no change to the SVN
> > >>>>> locations,
> > >>>>>>> to the URLs and to the "URL mapping/forwarding" (sorry, I do not
> > >> know
> > >>>>> the
> > >>>>>>> correct term here) for the update resources used by already
> > >> released
> > >>>>>>> versions.
> > >>>>>> mapping is the correct term. There will be no changes apart from
> (1)
> > >>> and
> > >>>>>> (2)
> > >>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> My proposal:
> > >>>>>>> I propose to follow infra's proposal mentioned above in (1) and
> > >> (2).
> > >>>>>> I have added it to infra tasks. We are currently waiting for the
> > >> cert
> > >>> to
> > >>>>> be
> > >>>>>> sent, then the first step will be to get https: working for wiki
> and
> > >>>>>> forums, second step is updates.o.o
> > >>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Best regards, Oliver.
> > >>>>>>
> > >>>>>> thx for a very clear mail, if nobody objects within the next 72
> > >>> hours,
> > >>>>> it
> > >>>>>> will be implemented as you propose.
> > >>>>>
> > >>>>> An extra step will be needed. Presumably we want the Apache CMS
> > >>>>> enabled so it publishes files from the SVN dir to the website dir.
> > >>>>> This doesn't happen automatically.
> > >>>>
> > >>>> that is not only an extra step, that can turn out to be a bigger
> > >>> challenge.
> > >>>> Having CMS enabled
> > >>>> is a very valid request, but then please choose a location inside
> the
> > >>>> web-site where CMS is already enabled.
> > >>>
> > >>> We already have two separate CMS publish targets from our SVN: /site
> > >>> (openoffice.apache.org) and /ooo-site (www.openoffice.org). Having
> a
> > >>> third one should not be a problem. I'd like to avoid the complexity
> > >>> that would occur if we had the same SVN dir connected to two
> different
> > >>> CMS targets.
> > >>
> > >> of course it can be done its software, its just more work and more
> admin
> > >> afterward.
> > >>
> > >> You would not have one svn dir connected to two different cms targets
> if
> > >> target dir is inside www.openoffice.org (which is what I suggested).
> > >>
> > >> updates.openoffice.org is logically just a pointer, and would
> normally
> > >> point inside the www domain (that is the simple solution), but can
> point
> > >> outside the www domain (which requires changes to httpd.conf, and an
> > extra
> > >> cms setup).
> > >
> > > from Oliver's commmunication [1], it seems that
> updates.openoffice.orghas
> > > been suggested to be *outside* the current web site domain, and
> followed
> > by
> > > his comments --
> > >
> > > "My opinion: I believe it would be good to have the update resources
> > > separated from the website resources. It would mean to move
> > > ^/openoffice/ooo-site/trunk/content/projects/aoo40/check.Update to
> > > ^/openoffice/updates-site/trunk/aoo40/check.Update"
> > >
> > > I feel we should NOT point the new update to any area within the
> existing
> > > www domain (we had some BIG problems initially trying to enable updates
> > > through the web server), so a new CMS would be needed. Hopefully, this
> is
> > > not a horrendous task.
> >
> > Infra will likely svnpubsub the new part of svn that has the update logic
> > as bare files. Projects are not required to use CMS, but are required to
> > use svnpubsub,
> >
> correct, that was (and is) the plan.
>
> >
> > I see no reason this needs to be pushed through CMS. None, it's too much
> > extra work.
> >
> +1
>
> I will get the things done (following oliver's proposal) during the
> weekend, so we only need to add the cert when it arrives.
>
> rgds
> jan I.
>
great on all counts...and I see the new area has been established!
>
> >
> > Thanks Oliver and Jan.
> >
> > Regards,
> > Dave
> >
> >
> > >
> > >
> > >
> > >> rgds
> > >> jan I.
> > >>
> > >>
> > >>>
> > >>> -Rob
> > >>>
> > >>>
> > >>>> rgds
> > >>>> jan i.
> > >>>>
> > >>>>>
> > >>>>> -Rob
> > >>>>>
> > >>>>>
> > >>>>>> rgds
> > >>>>>> jan I.
> > >>>>>>
> > >>>>>>
> > >>>>>>>
> > >>>>>>> On 05.06.2013 00:22, janI wrote:
> > >>>>>>>
> > >>>>>>>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
> > >>>>>>>>
> > >>>>>>>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org>
> > >>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> On 03/06/2013 Rob Weir wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> I think the concern is this:
> > >>>>>>>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
> > >>>>>>>>>>> http://update.openoffice.org> is not HTTPS.
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
> > >>>>> http://apache.org>
> > >>>>>>>>>>>> <
> > >>>>>>>>>>> https://ooo-site.openoffice.**apache.org<
> > >>>>> https://ooo-site.openoffice.apache.org>>
> > >>>>>>>>> supports SSL, but is
> > >>>>>>>>>
> > >>>>>>>>>> not considered "long term stable". The URL is an artifact of
> > >> the
> > >>> CMS
> > >>>>>>>>>>>> 3) We're looking for a stable URL. One could be
> > >>>>>>>>>>>> https://updates.openoffice.org****, but that requires an
> SSL
> > >>> cert
> > >>>>> for
> > >>>>>>>>>>>> *.openoffice.org. But will that be supported in time for
> the
> > >>> AOO
> > >>>>> 4.0
> > >>>>>>>>>>>> release?
> > >>>>>>>>>>>> 4) Backup plan is updates.openoffice.apache.org, which
> could
> > >> be
> > >>>>>>>>>>>> supported via SSL today, using the *.apache.org cert. If
> we
> > >> do
> > >>>>> that
> > >>>>>>>>>>>> we'd want to map that to its own CMS dir in SVN. so it can
> be
> > >>>>> updated
> > >>>>>>>>>>>> and published via the CMS.
> > >>>>>>>>>>> This is mostly correct, except the fact (in #2 and #4) that
> the
> > >>>>> current
> > >>>>>>>>>>> certificates only support x.apache.org and not
> x.y.apache.org:
> > >>> so
> > >>>>>>>>>>> https://ooo-site.apache.org is what is in the sources right
> > >> now
> > >>>>> (well,
> > >>>>>>>>>>> the last time I checked) and https://openoffice-updates.
> **a**
> > >>>>> pache.org<http://apache.org>
> > >>>>>>>>>>> <
> > >>>>>>>>>> https://openoffice-updates.**apache.org<
> > >>>>> https://openoffice-updates.apache.org>>(or
> > >>>>>>>>> something like that) should be
> > >>>>>>>>> used for the backup plan in #4.
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Hi
> > >>>>>>>>>>
> > >>>>>>>>>> I am confused, it seem we nearly all agree on
> > >>>>>>>>>> https://updates.openoffice.**orgbut <
> > >>>>> https://updates.openoffice.orgbut>not on the directory.
> > >>>>>>>>>>
> > >>>>>>>>>> The order for the cert is being processed, when the cert
> arrives
> > >>> it
> > >>>>>>>>>> needs
> > >>>>>>>>>> to be implemented on erebus-sll (our https: proxy), and we
> > >> (infra)
> > >>>>> need
> > >>>>>>>>> to
> > >>>>>>>>>
> > >>>>>>>>>> do some updates on the aoo servers.
> > >>>>>>>>>>
> > >>>>>>>>>> In order to do this work, I need:
> > >>>>>>>>>>
> > >>>>>>>>>> 1) which url (e.g. https://updates.openoffice.org**)
> > >>>>>>>>>> 2) should relate to which directory in svn.
> > >>>>>>>>>>
> > >>>>>>>>>> The last mails contains different proposal ranging from dont
> do
> > >> it
> > >>>>> for
> > >>>>>>>>> 4.0
> > >>>>>>>>>
> > >>>>>>>>>> to different dirs, that is something I cannot implement.
> > >>>>>>>>>>
> > >>>>>>>>>> We can also decide to forget it for https:updates.*, but I
> need
> > >> a
> > >>>>> single
> > >>>>>>>>>> decision to be able to implement it.
> > >>>>>>>>> Is the cert already here? Or do we have a few weeks to decide?
> > >>> I'd
> > >>>>>>>>> say, don't let this decision get in the way of deploying the
> cert
> > >>> and
> > >>>>>>>>> enabling it for the website, wikis, forums, etc. The update
> > >> site
> > >>>>>>>>> doesn't need to be enabled until shortly before AOO 4.0 is
> > >>> released.
> > >>>>>>>>>
> > >>>>>>>>> We have been promised a free cert, I just checked it is not yet
> > >> in
> > >>>>> our
> > >>>>>>>> hands.
> > >>>>>>>>
> > >>>>>>>> Wiki and other services with login, will be changed to https: to
> > >>>>> adhere to
> > >>>>>>>> asf/infra policy.
> > >>>>>>>> This will be done on infra initative, and the actual setup will
> be
> > >>> like
> > >>>>>>>> other servers in asf.
> > >>>>>>>>
> > >>>>>>>> update.o.o can come later, but it will definitively save work if
> > >> we
> > >>> do
> > >>>>> it
> > >>>>>>>> as one task. Of course if
> > >>>>>>>> the decision is to postpone after 4.0, it will be 2 tasks.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> And depending on when the cert arrives, we might not use it at
> > >> all
> > >>> for
> > >>>>>>>>> 4.0 updates. If it comes too late we'll just use an
> apache.org
> > >>>>>>>>> address. So we're really waiting for Infra on this, not the
> > >> other
> > >>>>>>>>> way around. We need an estimate for when the cert will be
> > >>> purchased
> > >>>>>>>>> so we can decide whether or not it will be used for 4.0
> updates.
> > >>>>>>>> As I understand it from the code, the end-user never sees this
> > >> url,
> > >>> so
> > >>>>> why
> > >>>>>>>> not stick with apache.org ?
> > >>>>>>>>
> > >>>>>>>> rgds
> > >>>>>>>> jan I.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> -Rob
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> rgds
> > >>>>>>>>>> jan I.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> Regards,
> > >>>>>>>>>>> Andrea.
> > >> ------------------------------****----------------------------**
> > >>>>>>>>> --**---------
> > >>>>>>>>>
> > >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**
> > >> pache.org
> > >>> <
> > >>>>> http://apache.org>
> > >>>>>>>>>>> <
> > >>>>>>>>>> dev-unsubscribe@openoffice.**apache.org<
> > >>>>> dev-unsubscribe@openoffice.apache.org>
> > >>>>>>>>>
> > >>>>>>>>>> For additional commands, e-mail:
> dev-help@openoffice.apache.org
> > >>>>>>>>>
> ------------------------------**------------------------------**
> > >>>>>>>>> ---------
> > >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**
> apache.org<
> > >>>>> dev-unsubscribe@openoffice.apache.org>
> > >>>>>>>>> For additional commands, e-mail:
> dev-help@openoffice.apache.org
> > >>>
> > ------------------------------**------------------------------**---------
> > >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> > >>>>> dev-unsubscribe@openoffice.apache.org>
> > >>>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >
> > >
> > >
> > > --
> > >
> >
> ----------------------------------------------------------------------------------------
> > > MzK
> > >
> > > "You can't believe one thing and do another.
> > > What you believe and what you do are the same thing."
> > > -- Leonard Peltier
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
--
----------------------------------------------------------------------------------------
MzK
"You can't believe one thing and do another.
What you believe and what you do are the same thing."
-- Leonard Peltier
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 6 June 2013 04:15, Dave Fisher <wa...@apache.org> wrote:
>
> On Jun 5, 2013, at 12:37 PM, Kay Schenk <ka...@gmail.com> wrote:
>
> > On Wed, Jun 5, 2013 at 8:50 AM, janI <ja...@apache.org> wrote:
> >
> >> On 5 June 2013 17:43, Rob Weir <ro...@apache.org> wrote:
> >>
> >>> On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
> >>>> On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
> >>>>
> >>>>> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
> >>>>>> On 5 June 2013 11:05, Oliver-Rainer Wittmann <
> >>> orwittmann@googlemail.com
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> sorry for top-posting, but I think it makes sense to clean up some
> >>>>> things.
> >>>>>>>
> >>>>>>> Some facts and my opinions:
> >>>>>>> (1)
> >>>>>>> Fact: In communication with infra, infra had proposed
> >>>>>>> https://updates.openoffice.**org/ <https://updates.openoffice.org/
> >>>
> >>> (
> >>>>>>> https://ooo-updates.**openoffice.org/<
> >>>>> https://ooo-updates.openoffice.org/>as the backup) as the URL for
> the
> >>>>> resources accessed by the update
> >>>>>>> functionality by AOO 4.0 and later. Nobody objects.
> >>>>>>> My opinion: I think we should go for it.
> >>>>>> +1, I will check dns, add whats missing, and when the cert arrives
> >>> update
> >>>>>> erebus-ssl (the https: proxy)
> >>>>>>
> >>>>>>>
> >>>>>>> (2)
> >>>>>>> Fact: In communication with infra, infra had proposed
> >>>>>>> ^/openoffice/updates-site/**trunk as the SVN location for the
> >>> resources
> >>>>>>> needed for the update functionality by AOO 4.0 and later.
> >>>>>>> My opinion: I believe it would be good to have the update resources
> >>>>>>> separated from the website resources. It would mean to move
> >>>>>>> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update
> >>> to
> >>>>>>> ^/openoffice/updates-site/**trunk/aoo40/check.Update
> >>>>>> +1 No problem, I can create the path in svn and add an alias (link)
> >> in
> >>>>> the
> >>>>>> httpd server. Btw this is easy to change later, it is a simple one
> >>> line,
> >>>>> in
> >>>>>> the configuration.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> (3)
> >>>>>>> My understanding: I think infra had in mind to "map"
> >>>>>>> https://updates.openoffice.org (resp. https://ooo-updates.**
> >>>>>>> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
> >>>>>>> ^/openoffice/updates-site/**trunk
> >>>>>>> Please correct me, if my understanding is not correct.
> >>>>>> it was correct, but changed to (2)
> >>>>>>
> >>>>>>>
> >>>>>>> (4)
> >>>>>>> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo
> >> 3.2.1
> >>>>> and
> >>>>>>> OOo 3.2 will remain at their current SVN location and will be
> >>> accessed
> >>>>> by
> >>>>>>> the current UpdateURLs.
> >>>>>>> My opinion: Thus, I believe there will be no change to the SVN
> >>>>> locations,
> >>>>>>> to the URLs and to the "URL mapping/forwarding" (sorry, I do not
> >> know
> >>>>> the
> >>>>>>> correct term here) for the update resources used by already
> >> released
> >>>>>>> versions.
> >>>>>> mapping is the correct term. There will be no changes apart from (1)
> >>> and
> >>>>>> (2)
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> My proposal:
> >>>>>>> I propose to follow infra's proposal mentioned above in (1) and
> >> (2).
> >>>>>> I have added it to infra tasks. We are currently waiting for the
> >> cert
> >>> to
> >>>>> be
> >>>>>> sent, then the first step will be to get https: working for wiki and
> >>>>>> forums, second step is updates.o.o
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Best regards, Oliver.
> >>>>>>
> >>>>>> thx for a very clear mail, if nobody objects within the next 72
> >>> hours,
> >>>>> it
> >>>>>> will be implemented as you propose.
> >>>>>
> >>>>> An extra step will be needed. Presumably we want the Apache CMS
> >>>>> enabled so it publishes files from the SVN dir to the website dir.
> >>>>> This doesn't happen automatically.
> >>>>
> >>>> that is not only an extra step, that can turn out to be a bigger
> >>> challenge.
> >>>> Having CMS enabled
> >>>> is a very valid request, but then please choose a location inside the
> >>>> web-site where CMS is already enabled.
> >>>
> >>> We already have two separate CMS publish targets from our SVN: /site
> >>> (openoffice.apache.org) and /ooo-site (www.openoffice.org). Having a
> >>> third one should not be a problem. I'd like to avoid the complexity
> >>> that would occur if we had the same SVN dir connected to two different
> >>> CMS targets.
> >>
> >> of course it can be done its software, its just more work and more admin
> >> afterward.
> >>
> >> You would not have one svn dir connected to two different cms targets if
> >> target dir is inside www.openoffice.org (which is what I suggested).
> >>
> >> updates.openoffice.org is logically just a pointer, and would normally
> >> point inside the www domain (that is the simple solution), but can point
> >> outside the www domain (which requires changes to httpd.conf, and an
> extra
> >> cms setup).
> >
> > from Oliver's commmunication [1], it seems that updates.openoffice.orghas
> > been suggested to be *outside* the current web site domain, and followed
> by
> > his comments --
> >
> > "My opinion: I believe it would be good to have the update resources
> > separated from the website resources. It would mean to move
> > ^/openoffice/ooo-site/trunk/content/projects/aoo40/check.Update to
> > ^/openoffice/updates-site/trunk/aoo40/check.Update"
> >
> > I feel we should NOT point the new update to any area within the existing
> > www domain (we had some BIG problems initially trying to enable updates
> > through the web server), so a new CMS would be needed. Hopefully, this is
> > not a horrendous task.
>
> Infra will likely svnpubsub the new part of svn that has the update logic
> as bare files. Projects are not required to use CMS, but are required to
> use svnpubsub,
>
correct, that was (and is) the plan.
>
> I see no reason this needs to be pushed through CMS. None, it's too much
> extra work.
>
+1
I will get the things done (following oliver's proposal) during the
weekend, so we only need to add the cert when it arrives.
rgds
jan I.
>
> Thanks Oliver and Jan.
>
> Regards,
> Dave
>
>
> >
> >
> >
> >> rgds
> >> jan I.
> >>
> >>
> >>>
> >>> -Rob
> >>>
> >>>
> >>>> rgds
> >>>> jan i.
> >>>>
> >>>>>
> >>>>> -Rob
> >>>>>
> >>>>>
> >>>>>> rgds
> >>>>>> jan I.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> On 05.06.2013 00:22, janI wrote:
> >>>>>>>
> >>>>>>>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
> >>>>>>>>
> >>>>>>>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org>
> >>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 03/06/2013 Rob Weir wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I think the concern is this:
> >>>>>>>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
> >>>>>>>>>>> http://update.openoffice.org> is not HTTPS.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
> >>>>> http://apache.org>
> >>>>>>>>>>>> <
> >>>>>>>>>>> https://ooo-site.openoffice.**apache.org<
> >>>>> https://ooo-site.openoffice.apache.org>>
> >>>>>>>>> supports SSL, but is
> >>>>>>>>>
> >>>>>>>>>> not considered "long term stable". The URL is an artifact of
> >> the
> >>> CMS
> >>>>>>>>>>>> 3) We're looking for a stable URL. One could be
> >>>>>>>>>>>> https://updates.openoffice.org****, but that requires an SSL
> >>> cert
> >>>>> for
> >>>>>>>>>>>> *.openoffice.org. But will that be supported in time for the
> >>> AOO
> >>>>> 4.0
> >>>>>>>>>>>> release?
> >>>>>>>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could
> >> be
> >>>>>>>>>>>> supported via SSL today, using the *.apache.org cert. If we
> >> do
> >>>>> that
> >>>>>>>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be
> >>>>> updated
> >>>>>>>>>>>> and published via the CMS.
> >>>>>>>>>>> This is mostly correct, except the fact (in #2 and #4) that the
> >>>>> current
> >>>>>>>>>>> certificates only support x.apache.org and not x.y.apache.org:
> >>> so
> >>>>>>>>>>> https://ooo-site.apache.org is what is in the sources right
> >> now
> >>>>> (well,
> >>>>>>>>>>> the last time I checked) and https://openoffice-updates.**a**
> >>>>> pache.org<http://apache.org>
> >>>>>>>>>>> <
> >>>>>>>>>> https://openoffice-updates.**apache.org<
> >>>>> https://openoffice-updates.apache.org>>(or
> >>>>>>>>> something like that) should be
> >>>>>>>>> used for the backup plan in #4.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Hi
> >>>>>>>>>>
> >>>>>>>>>> I am confused, it seem we nearly all agree on
> >>>>>>>>>> https://updates.openoffice.**orgbut <
> >>>>> https://updates.openoffice.orgbut>not on the directory.
> >>>>>>>>>>
> >>>>>>>>>> The order for the cert is being processed, when the cert arrives
> >>> it
> >>>>>>>>>> needs
> >>>>>>>>>> to be implemented on erebus-sll (our https: proxy), and we
> >> (infra)
> >>>>> need
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>>> do some updates on the aoo servers.
> >>>>>>>>>>
> >>>>>>>>>> In order to do this work, I need:
> >>>>>>>>>>
> >>>>>>>>>> 1) which url (e.g. https://updates.openoffice.org**)
> >>>>>>>>>> 2) should relate to which directory in svn.
> >>>>>>>>>>
> >>>>>>>>>> The last mails contains different proposal ranging from dont do
> >> it
> >>>>> for
> >>>>>>>>> 4.0
> >>>>>>>>>
> >>>>>>>>>> to different dirs, that is something I cannot implement.
> >>>>>>>>>>
> >>>>>>>>>> We can also decide to forget it for https:updates.*, but I need
> >> a
> >>>>> single
> >>>>>>>>>> decision to be able to implement it.
> >>>>>>>>> Is the cert already here? Or do we have a few weeks to decide?
> >>> I'd
> >>>>>>>>> say, don't let this decision get in the way of deploying the cert
> >>> and
> >>>>>>>>> enabling it for the website, wikis, forums, etc. The update
> >> site
> >>>>>>>>> doesn't need to be enabled until shortly before AOO 4.0 is
> >>> released.
> >>>>>>>>>
> >>>>>>>>> We have been promised a free cert, I just checked it is not yet
> >> in
> >>>>> our
> >>>>>>>> hands.
> >>>>>>>>
> >>>>>>>> Wiki and other services with login, will be changed to https: to
> >>>>> adhere to
> >>>>>>>> asf/infra policy.
> >>>>>>>> This will be done on infra initative, and the actual setup will be
> >>> like
> >>>>>>>> other servers in asf.
> >>>>>>>>
> >>>>>>>> update.o.o can come later, but it will definitively save work if
> >> we
> >>> do
> >>>>> it
> >>>>>>>> as one task. Of course if
> >>>>>>>> the decision is to postpone after 4.0, it will be 2 tasks.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> And depending on when the cert arrives, we might not use it at
> >> all
> >>> for
> >>>>>>>>> 4.0 updates. If it comes too late we'll just use an apache.org
> >>>>>>>>> address. So we're really waiting for Infra on this, not the
> >> other
> >>>>>>>>> way around. We need an estimate for when the cert will be
> >>> purchased
> >>>>>>>>> so we can decide whether or not it will be used for 4.0 updates.
> >>>>>>>> As I understand it from the code, the end-user never sees this
> >> url,
> >>> so
> >>>>> why
> >>>>>>>> not stick with apache.org ?
> >>>>>>>>
> >>>>>>>> rgds
> >>>>>>>> jan I.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -Rob
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> rgds
> >>>>>>>>>> jan I.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Andrea.
> >> ------------------------------****----------------------------**
> >>>>>>>>> --**---------
> >>>>>>>>>
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**
> >> pache.org
> >>> <
> >>>>> http://apache.org>
> >>>>>>>>>>> <
> >>>>>>>>>> dev-unsubscribe@openoffice.**apache.org<
> >>>>> dev-unsubscribe@openoffice.apache.org>
> >>>>>>>>>
> >>>>>>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>>>>>> ------------------------------**------------------------------**
> >>>>>>>>> ---------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> >>>>> dev-unsubscribe@openoffice.apache.org>
> >>>>>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>
> ------------------------------**------------------------------**---------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> >>>>> dev-unsubscribe@openoffice.apache.org>
> >>>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
> >
> > --
> >
> ----------------------------------------------------------------------------------------
> > MzK
> >
> > "You can't believe one thing and do another.
> > What you believe and what you do are the same thing."
> > -- Leonard Peltier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: updates.openoffice.org
Posted by Dave Fisher <wa...@apache.org>.
On Jun 5, 2013, at 12:37 PM, Kay Schenk <ka...@gmail.com> wrote:
> On Wed, Jun 5, 2013 at 8:50 AM, janI <ja...@apache.org> wrote:
>
>> On 5 June 2013 17:43, Rob Weir <ro...@apache.org> wrote:
>>
>>> On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
>>>> On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
>>>>
>>>>> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
>>>>>> On 5 June 2013 11:05, Oliver-Rainer Wittmann <
>>> orwittmann@googlemail.com
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> sorry for top-posting, but I think it makes sense to clean up some
>>>>> things.
>>>>>>>
>>>>>>> Some facts and my opinions:
>>>>>>> (1)
>>>>>>> Fact: In communication with infra, infra had proposed
>>>>>>> https://updates.openoffice.**org/ <https://updates.openoffice.org/
>>>
>>> (
>>>>>>> https://ooo-updates.**openoffice.org/<
>>>>> https://ooo-updates.openoffice.org/>as the backup) as the URL for the
>>>>> resources accessed by the update
>>>>>>> functionality by AOO 4.0 and later. Nobody objects.
>>>>>>> My opinion: I think we should go for it.
>>>>>> +1, I will check dns, add whats missing, and when the cert arrives
>>> update
>>>>>> erebus-ssl (the https: proxy)
>>>>>>
>>>>>>>
>>>>>>> (2)
>>>>>>> Fact: In communication with infra, infra had proposed
>>>>>>> ^/openoffice/updates-site/**trunk as the SVN location for the
>>> resources
>>>>>>> needed for the update functionality by AOO 4.0 and later.
>>>>>>> My opinion: I believe it would be good to have the update resources
>>>>>>> separated from the website resources. It would mean to move
>>>>>>> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update
>>> to
>>>>>>> ^/openoffice/updates-site/**trunk/aoo40/check.Update
>>>>>> +1 No problem, I can create the path in svn and add an alias (link)
>> in
>>>>> the
>>>>>> httpd server. Btw this is easy to change later, it is a simple one
>>> line,
>>>>> in
>>>>>> the configuration.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> (3)
>>>>>>> My understanding: I think infra had in mind to "map"
>>>>>>> https://updates.openoffice.org (resp. https://ooo-updates.**
>>>>>>> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
>>>>>>> ^/openoffice/updates-site/**trunk
>>>>>>> Please correct me, if my understanding is not correct.
>>>>>> it was correct, but changed to (2)
>>>>>>
>>>>>>>
>>>>>>> (4)
>>>>>>> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo
>> 3.2.1
>>>>> and
>>>>>>> OOo 3.2 will remain at their current SVN location and will be
>>> accessed
>>>>> by
>>>>>>> the current UpdateURLs.
>>>>>>> My opinion: Thus, I believe there will be no change to the SVN
>>>>> locations,
>>>>>>> to the URLs and to the "URL mapping/forwarding" (sorry, I do not
>> know
>>>>> the
>>>>>>> correct term here) for the update resources used by already
>> released
>>>>>>> versions.
>>>>>> mapping is the correct term. There will be no changes apart from (1)
>>> and
>>>>>> (2)
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My proposal:
>>>>>>> I propose to follow infra's proposal mentioned above in (1) and
>> (2).
>>>>>> I have added it to infra tasks. We are currently waiting for the
>> cert
>>> to
>>>>> be
>>>>>> sent, then the first step will be to get https: working for wiki and
>>>>>> forums, second step is updates.o.o
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best regards, Oliver.
>>>>>>
>>>>>> thx for a very clear mail, if nobody objects within the next 72
>>> hours,
>>>>> it
>>>>>> will be implemented as you propose.
>>>>>
>>>>> An extra step will be needed. Presumably we want the Apache CMS
>>>>> enabled so it publishes files from the SVN dir to the website dir.
>>>>> This doesn't happen automatically.
>>>>
>>>> that is not only an extra step, that can turn out to be a bigger
>>> challenge.
>>>> Having CMS enabled
>>>> is a very valid request, but then please choose a location inside the
>>>> web-site where CMS is already enabled.
>>>
>>> We already have two separate CMS publish targets from our SVN: /site
>>> (openoffice.apache.org) and /ooo-site (www.openoffice.org). Having a
>>> third one should not be a problem. I'd like to avoid the complexity
>>> that would occur if we had the same SVN dir connected to two different
>>> CMS targets.
>>
>> of course it can be done its software, its just more work and more admin
>> afterward.
>>
>> You would not have one svn dir connected to two different cms targets if
>> target dir is inside www.openoffice.org (which is what I suggested).
>>
>> updates.openoffice.org is logically just a pointer, and would normally
>> point inside the www domain (that is the simple solution), but can point
>> outside the www domain (which requires changes to httpd.conf, and an extra
>> cms setup).
>
> from Oliver's commmunication [1], it seems that updates.openoffice.org has
> been suggested to be *outside* the current web site domain, and followed by
> his comments --
>
> "My opinion: I believe it would be good to have the update resources
> separated from the website resources. It would mean to move
> ^/openoffice/ooo-site/trunk/content/projects/aoo40/check.Update to
> ^/openoffice/updates-site/trunk/aoo40/check.Update"
>
> I feel we should NOT point the new update to any area within the existing
> www domain (we had some BIG problems initially trying to enable updates
> through the web server), so a new CMS would be needed. Hopefully, this is
> not a horrendous task.
Infra will likely svnpubsub the new part of svn that has the update logic as bare files. Projects are not required to use CMS, but are required to use svnpubsub,
I see no reason this needs to be pushed through CMS. None, it's too much extra work.
Thanks Oliver and Jan.
Regards,
Dave
>
>
>
>> rgds
>> jan I.
>>
>>
>>>
>>> -Rob
>>>
>>>
>>>> rgds
>>>> jan i.
>>>>
>>>>>
>>>>> -Rob
>>>>>
>>>>>
>>>>>> rgds
>>>>>> jan I.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 05.06.2013 00:22, janI wrote:
>>>>>>>
>>>>>>>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
>>>>>>>>
>>>>>>>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org>
>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 03/06/2013 Rob Weir wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think the concern is this:
>>>>>>>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
>>>>>>>>>>> http://update.openoffice.org> is not HTTPS.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
>>>>> http://apache.org>
>>>>>>>>>>>> <
>>>>>>>>>>> https://ooo-site.openoffice.**apache.org<
>>>>> https://ooo-site.openoffice.apache.org>>
>>>>>>>>> supports SSL, but is
>>>>>>>>>
>>>>>>>>>> not considered "long term stable". The URL is an artifact of
>> the
>>> CMS
>>>>>>>>>>>> 3) We're looking for a stable URL. One could be
>>>>>>>>>>>> https://updates.openoffice.org****, but that requires an SSL
>>> cert
>>>>> for
>>>>>>>>>>>> *.openoffice.org. But will that be supported in time for the
>>> AOO
>>>>> 4.0
>>>>>>>>>>>> release?
>>>>>>>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could
>> be
>>>>>>>>>>>> supported via SSL today, using the *.apache.org cert. If we
>> do
>>>>> that
>>>>>>>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be
>>>>> updated
>>>>>>>>>>>> and published via the CMS.
>>>>>>>>>>> This is mostly correct, except the fact (in #2 and #4) that the
>>>>> current
>>>>>>>>>>> certificates only support x.apache.org and not x.y.apache.org:
>>> so
>>>>>>>>>>> https://ooo-site.apache.org is what is in the sources right
>> now
>>>>> (well,
>>>>>>>>>>> the last time I checked) and https://openoffice-updates.**a**
>>>>> pache.org<http://apache.org>
>>>>>>>>>>> <
>>>>>>>>>> https://openoffice-updates.**apache.org<
>>>>> https://openoffice-updates.apache.org>>(or
>>>>>>>>> something like that) should be
>>>>>>>>> used for the backup plan in #4.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> I am confused, it seem we nearly all agree on
>>>>>>>>>> https://updates.openoffice.**orgbut <
>>>>> https://updates.openoffice.orgbut>not on the directory.
>>>>>>>>>>
>>>>>>>>>> The order for the cert is being processed, when the cert arrives
>>> it
>>>>>>>>>> needs
>>>>>>>>>> to be implemented on erebus-sll (our https: proxy), and we
>> (infra)
>>>>> need
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>>> do some updates on the aoo servers.
>>>>>>>>>>
>>>>>>>>>> In order to do this work, I need:
>>>>>>>>>>
>>>>>>>>>> 1) which url (e.g. https://updates.openoffice.org**)
>>>>>>>>>> 2) should relate to which directory in svn.
>>>>>>>>>>
>>>>>>>>>> The last mails contains different proposal ranging from dont do
>> it
>>>>> for
>>>>>>>>> 4.0
>>>>>>>>>
>>>>>>>>>> to different dirs, that is something I cannot implement.
>>>>>>>>>>
>>>>>>>>>> We can also decide to forget it for https:updates.*, but I need
>> a
>>>>> single
>>>>>>>>>> decision to be able to implement it.
>>>>>>>>> Is the cert already here? Or do we have a few weeks to decide?
>>> I'd
>>>>>>>>> say, don't let this decision get in the way of deploying the cert
>>> and
>>>>>>>>> enabling it for the website, wikis, forums, etc. The update
>> site
>>>>>>>>> doesn't need to be enabled until shortly before AOO 4.0 is
>>> released.
>>>>>>>>>
>>>>>>>>> We have been promised a free cert, I just checked it is not yet
>> in
>>>>> our
>>>>>>>> hands.
>>>>>>>>
>>>>>>>> Wiki and other services with login, will be changed to https: to
>>>>> adhere to
>>>>>>>> asf/infra policy.
>>>>>>>> This will be done on infra initative, and the actual setup will be
>>> like
>>>>>>>> other servers in asf.
>>>>>>>>
>>>>>>>> update.o.o can come later, but it will definitively save work if
>> we
>>> do
>>>>> it
>>>>>>>> as one task. Of course if
>>>>>>>> the decision is to postpone after 4.0, it will be 2 tasks.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> And depending on when the cert arrives, we might not use it at
>> all
>>> for
>>>>>>>>> 4.0 updates. If it comes too late we'll just use an apache.org
>>>>>>>>> address. So we're really waiting for Infra on this, not the
>> other
>>>>>>>>> way around. We need an estimate for when the cert will be
>>> purchased
>>>>>>>>> so we can decide whether or not it will be used for 4.0 updates.
>>>>>>>> As I understand it from the code, the end-user never sees this
>> url,
>>> so
>>>>> why
>>>>>>>> not stick with apache.org ?
>>>>>>>>
>>>>>>>> rgds
>>>>>>>> jan I.
>>>>>>>>
>>>>>>>>
>>>>>>>>> -Rob
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> rgds
>>>>>>>>>> jan I.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Andrea.
>> ------------------------------****----------------------------**
>>>>>>>>> --**---------
>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**
>> pache.org
>>> <
>>>>> http://apache.org>
>>>>>>>>>>> <
>>>>>>>>>> dev-unsubscribe@openoffice.**apache.org<
>>>>> dev-unsubscribe@openoffice.apache.org>
>>>>>>>>>
>>>>>>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>>>>> ------------------------------**------------------------------**
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>>>>> dev-unsubscribe@openoffice.apache.org>
>>>>>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>> ------------------------------**------------------------------**---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>>>>> dev-unsubscribe@openoffice.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
>
> --
> ----------------------------------------------------------------------------------------
> MzK
>
> "You can't believe one thing and do another.
> What you believe and what you do are the same thing."
> -- Leonard Peltier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Jun 5, 2013 at 10:03 AM, janI <ja...@apache.org> wrote:
> On 5 June 2013 18:37, Kay Schenk <ka...@gmail.com> wrote:
>
> > On Wed, Jun 5, 2013 at 8:50 AM, janI <ja...@apache.org> wrote:
> >
> > > On 5 June 2013 17:43, Rob Weir <ro...@apache.org> wrote:
> > >
> > > > On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
> > > > > On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
> > > > >
> > > > >> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
> > > > >> > On 5 June 2013 11:05, Oliver-Rainer Wittmann <
> > > > orwittmann@googlemail.com
> > > > >> >wrote:
> > > > >> >
> > > > >> >> Hi,
> > > > >> >>
> > > > >> >> sorry for top-posting, but I think it makes sense to clean up
> > some
> > > > >> things.
> > > > >> >>
> > > > >> >> Some facts and my opinions:
> > > > >> >> (1)
> > > > >> >> Fact: In communication with infra, infra had proposed
> > > > >> >> https://updates.openoffice.**org/ <
> > https://updates.openoffice.org/
> > > >
> > > > (
> > > > >> >> https://ooo-updates.**openoffice.org/<
> > > > >> https://ooo-updates.openoffice.org/>as the backup) as the URL for
> > the
> > > > >> resources accessed by the update
> > > > >> >> functionality by AOO 4.0 and later. Nobody objects.
> > > > >> >> My opinion: I think we should go for it.
> > > > >> >>
> > > > >> > +1, I will check dns, add whats missing, and when the cert
> arrives
> > > > update
> > > > >> > erebus-ssl (the https: proxy)
> > > > >> >
> > > > >> >>
> > > > >> >> (2)
> > > > >> >> Fact: In communication with infra, infra had proposed
> > > > >> >> ^/openoffice/updates-site/**trunk as the SVN location for the
> > > > resources
> > > > >> >> needed for the update functionality by AOO 4.0 and later.
> > > > >> >> My opinion: I believe it would be good to have the update
> > resources
> > > > >> >> separated from the website resources. It would mean to move
> > > > >> >>
> > ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update
> > > > to
> > > > >> >> ^/openoffice/updates-site/**trunk/aoo40/check.Update
> > > > >> >>
> > > > >> > +1 No problem, I can create the path in svn and add an alias
> > (link)
> > > in
> > > > >> the
> > > > >> > httpd server. Btw this is easy to change later, it is a simple
> one
> > > > line,
> > > > >> in
> > > > >> > the configuration.
> > > > >> >
> > > > >> >
> > > > >> >>
> > > > >> >> (3)
> > > > >> >> My understanding: I think infra had in mind to "map"
> > > > >> >> https://updates.openoffice.org (resp. https://ooo-updates.**
> > > > >> >> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
> > > > >> >> ^/openoffice/updates-site/**trunk
> > > > >> >> Please correct me, if my understanding is not correct.
> > > > >> >>
> > > > >> > it was correct, but changed to (2)
> > > > >> >
> > > > >> >>
> > > > >> >> (4)
> > > > >> >> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo
> > > 3.2.1
> > > > >> and
> > > > >> >> OOo 3.2 will remain at their current SVN location and will be
> > > > accessed
> > > > >> by
> > > > >> >> the current UpdateURLs.
> > > > >> >> My opinion: Thus, I believe there will be no change to the SVN
> > > > >> locations,
> > > > >> >> to the URLs and to the "URL mapping/forwarding" (sorry, I do
> not
> > > know
> > > > >> the
> > > > >> >> correct term here) for the update resources used by already
> > > released
> > > > >> >> versions.
> > > > >> >>
> > > > >> > mapping is the correct term. There will be no changes apart from
> > (1)
> > > > and
> > > > >> > (2)
> > > > >> >
> > > > >> >>
> > > > >> >>
> > > > >> >> My proposal:
> > > > >> >> I propose to follow infra's proposal mentioned above in (1) and
> > > (2).
> > > > >> >>
> > > > >> > I have added it to infra tasks. We are currently waiting for the
> > > cert
> > > > to
> > > > >> be
> > > > >> > sent, then the first step will be to get https: working for wiki
> > and
> > > > >> > forums, second step is updates.o.o
> > > > >> >
> > > > >> >>
> > > > >> >>
> > > > >> >> Best regards, Oliver.
> > > > >> >
> > > > >> > thx for a very clear mail, if nobody objects within the next 72
> > > > hours,
> > > > >> it
> > > > >> > will be implemented as you propose.
> > > > >> >
> > > > >>
> > > > >> An extra step will be needed. Presumably we want the Apache CMS
> > > > >> enabled so it publishes files from the SVN dir to the website dir.
> > > > >> This doesn't happen automatically.
> > > > >>
> > > > >
> > > > > that is not only an extra step, that can turn out to be a bigger
> > > > challenge.
> > > > > Having CMS enabled
> > > > > is a very valid request, but then please choose a location inside
> the
> > > > > web-site where CMS is already enabled.
> > > > >
> > > >
> > > > We already have two separate CMS publish targets from our SVN: /site
> > > > (openoffice.apache.org) and /ooo-site (www.openoffice.org). Having
> a
> > > > third one should not be a problem. I'd like to avoid the complexity
> > > > that would occur if we had the same SVN dir connected to two
> different
> > > > CMS targets.
> > > >
> > >
> > > of course it can be done its software, its just more work and more
> admin
> > > afterward.
> > >
> > > You would not have one svn dir connected to two different cms targets
> if
> > > target dir is inside www.openoffice.org (which is what I suggested).
> > >
> > > updates.openoffice.org is logically just a pointer, and would normally
> > > point inside the www domain (that is the simple solution), but can
> point
> > > outside the www domain (which requires changes to httpd.conf, and an
> > extra
> > > cms setup).
> > >
> >
> > from Oliver's commmunication [1], it seems that updates.openoffice.orghas
> > been suggested to be *outside* the current web site domain, and followed
> by
> > his comments --
> >
> > "My opinion: I believe it would be good to have the update resources
> > separated from the website resources. It would mean to move
> > ^/openoffice/ooo-site/trunk/content/projects/aoo40/check.Update to
> > ^/openoffice/updates-site/trunk/aoo40/check.Update"
> >
> > I feel we should NOT point the new update to any area within the existing
> > www domain (we had some BIG problems initially trying to enable updates
> > through the web server), so a new CMS would be needed. Hopefully, this is
> > not a horrendous task.
> >
>
> Of course I will not cause big problems, but why does
>
> - ^/openoffice/ooo-site/trunk/**
> >
> > content/projects/update/**aoo341/ used by
> > UpdateURL http://www.openoffice.org/**projects/update/aoo341/check.**
>
> work,
Well this particular one doesn't do anything--it's a placeholder dummy
routine...so it definitely wouldn't cause any problems. This was the
UpdateURL packaged with AOO34 in the versionrc file created from--
http://svn.apache.org/viewvc/openoffice/branches/AOO34/main/instsetoo_native/util/openoffice.lst?revision=1413471&view=markup
but the update service was not implemented -- say going to 3.4.1.
I have no other explanation. Apparently, we have had no "live" test
updating from 3.4.0 to 3.4.1.
Functioning feeds for previous versions are in:
http://www.openoffice.org/projects/update34
http://www.openoffice.org/projects/update35
http://www.openoffice.org/projects/update36
http://www.openoffice.org/projects/update38
So, this is the other issue. Changing placement of this URL will likely
entail rebuilding the current snapshot for 4.0 with the new URL.
I think the main concern, and the suggestion of an isolated new web area is
the amount of traffic that could get generated all at once by folks that
have auto update enabled. I think this is a very good idea.
> while a new aoo40 along the same lines cause big problems ?
>
> the URL is just an alias/mapping to the location inside the tree (or if you
> prefer a shortcut notation), it is not a special httpd or anything.
>
yes, but they can contain the actual feeds that trigger processing/updating
OpenOffice.
see, for example:
http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update
>
> rgds
> jan I.
>
>
> >
> >
> >
> > > rgds
> > > jan I.
> > >
> > >
> > > >
> > > > -Rob
> > > >
> > > >
> > > > > rgds
> > > > > jan i.
> > > > >
> > > > >>
> > > > >> -Rob
> > > > >>
> > > > >>
> > > > >> > rgds
> > > > >> > jan I.
> > > > >> >
> > > > >> >
> > > > >> >>
> > > > >> >> On 05.06.2013 00:22, janI wrote:
> > > > >> >>
> > > > >> >>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
> > > > >> >>>
> > > > >> >>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org>
> wrote:
> > > > >> >>>>
> > > > >> >>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org>
> > > > wrote:
> > > > >> >>>>>
> > > > >> >>>>> On 03/06/2013 Rob Weir wrote:
> > > > >> >>>>>>
> > > > >> >>>>>> I think the concern is this:
> > > > >> >>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
> > > > >> >>>>>>>
> > > > >> >>>>>> http://update.openoffice.org> is not HTTPS.
> > > > >> >>>>
> > > > >> >>>>>
> > > > >> >>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
> > > > >> http://apache.org>
> > > > >> >>>>>>> <
> > > > >> >>>>>>>
> > > > >> >>>>>> https://ooo-site.openoffice.**apache.org<
> > > > >> https://ooo-site.openoffice.apache.org>>
> > > > >> >>>> supports SSL, but is
> > > > >> >>>>
> > > > >> >>>>> not considered "long term stable". The URL is an artifact
> of
> > > the
> > > > CMS
> > > > >> >>>>>>> 3) We're looking for a stable URL. One could be
> > > > >> >>>>>>> https://updates.openoffice.org****, but that requires an
> > SSL
> > > > cert
> > > > >> for
> > > > >> >>>>>>> *.openoffice.org. But will that be supported in time for
> > the
> > > > AOO
> > > > >> 4.0
> > > > >> >>>>>>> release?
> > > > >> >>>>>>> 4) Backup plan is updates.openoffice.apache.org, which
> > could
> > > be
> > > > >> >>>>>>> supported via SSL today, using the *.apache.org cert. If
> > we
> > > do
> > > > >> that
> > > > >> >>>>>>> we'd want to map that to its own CMS dir in SVN. so it can
> > be
> > > > >> updated
> > > > >> >>>>>>> and published via the CMS.
> > > > >> >>>>>>>
> > > > >> >>>>>>>
> > > > >> >>>>>> This is mostly correct, except the fact (in #2 and #4) that
> > the
> > > > >> current
> > > > >> >>>>>> certificates only support x.apache.org and not
> > x.y.apache.org:
> > > > so
> > > > >> >>>>>> https://ooo-site.apache.org is what is in the sources
> right
> > > now
> > > > >> (well,
> > > > >> >>>>>> the last time I checked) and https://openoffice-updates.
> > **a**
> > > > >> pache.org<http://apache.org>
> > > > >> >>>>>> <
> > > > >> >>>>>>
> > > > >> >>>>> https://openoffice-updates.**apache.org<
> > > > >> https://openoffice-updates.apache.org>>(or
> > > > >> >>>> something like that) should be
> > > > >> >>>> used for the backup plan in #4.
> > > > >> >>>>
> > > > >> >>>>>
> > > > >> >>>>>>
> > > > >> >>>>> Hi
> > > > >> >>>>>
> > > > >> >>>>> I am confused, it seem we nearly all agree on
> > > > >> >>>>> https://updates.openoffice.**orgbut <
> > > > >> https://updates.openoffice.orgbut>not on the directory.
> > > > >> >>>>>
> > > > >> >>>>> The order for the cert is being processed, when the cert
> > arrives
> > > > it
> > > > >> >>>>> needs
> > > > >> >>>>> to be implemented on erebus-sll (our https: proxy), and we
> > > (infra)
> > > > >> need
> > > > >> >>>>>
> > > > >> >>>> to
> > > > >> >>>>
> > > > >> >>>>> do some updates on the aoo servers.
> > > > >> >>>>>
> > > > >> >>>>> In order to do this work, I need:
> > > > >> >>>>>
> > > > >> >>>>> 1) which url (e.g. https://updates.openoffice.org**)
> > > > >> >>>>> 2) should relate to which directory in svn.
> > > > >> >>>>>
> > > > >> >>>>> The last mails contains different proposal ranging from dont
> > do
> > > it
> > > > >> for
> > > > >> >>>>>
> > > > >> >>>> 4.0
> > > > >> >>>>
> > > > >> >>>>> to different dirs, that is something I cannot implement.
> > > > >> >>>>>
> > > > >> >>>>> We can also decide to forget it for https:updates.*, but I
> > need
> > > a
> > > > >> single
> > > > >> >>>>> decision to be able to implement it.
> > > > >> >>>>>
> > > > >> >>>>>
> > > > >> >>>> Is the cert already here? Or do we have a few weeks to
> decide?
> > > > I'd
> > > > >> >>>> say, don't let this decision get in the way of deploying the
> > cert
> > > > and
> > > > >> >>>> enabling it for the website, wikis, forums, etc. The update
> > > site
> > > > >> >>>> doesn't need to be enabled until shortly before AOO 4.0 is
> > > > released.
> > > > >> >>>>
> > > > >> >>>> We have been promised a free cert, I just checked it is not
> > yet
> > > in
> > > > >> our
> > > > >> >>> hands.
> > > > >> >>>
> > > > >> >>> Wiki and other services with login, will be changed to https:
> to
> > > > >> adhere to
> > > > >> >>> asf/infra policy.
> > > > >> >>> This will be done on infra initative, and the actual setup
> will
> > be
> > > > like
> > > > >> >>> other servers in asf.
> > > > >> >>>
> > > > >> >>> update.o.o can come later, but it will definitively save work
> if
> > > we
> > > > do
> > > > >> it
> > > > >> >>> as one task. Of course if
> > > > >> >>> the decision is to postpone after 4.0, it will be 2 tasks.
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>> And depending on when the cert arrives, we might not use it
> at
> > > all
> > > > for
> > > > >> >>>> 4.0 updates. If it comes too late we'll just use an
> > apache.org
> > > > >> >>>> address. So we're really waiting for Infra on this, not the
> > > other
> > > > >> >>>> way around. We need an estimate for when the cert will be
> > > > purchased
> > > > >> >>>> so we can decide whether or not it will be used for 4.0
> > updates.
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>> As I understand it from the code, the end-user never sees this
> > > url,
> > > > so
> > > > >> why
> > > > >> >>> not stick with apache.org ?
> > > > >> >>>
> > > > >> >>> rgds
> > > > >> >>> jan I.
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>> -Rob
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>> rgds
> > > > >> >>>>> jan I.
> > > > >> >>>>>
> > > > >> >>>>>
> > > > >> >>>>>> Regards,
> > > > >> >>>>>> Andrea.
> > > > >> >>>>>>
> > > > >> >>>>>>
> > > > >> >>>>>>
> > > > >> >>>>>>
> > > ------------------------------****----------------------------**
> > > > >> >>>> --**---------
> > > > >> >>>>
> > > > >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**
> > > pache.org
> > > > <
> > > > >> http://apache.org>
> > > > >> >>>>>> <
> > > > >> >>>>>>
> > > > >> >>>>> dev-unsubscribe@openoffice.**apache.org<
> > > > >> dev-unsubscribe@openoffice.apache.org>
> > > > >> >>>> >
> > > > >> >>>>
> > > > >> >>>>> For additional commands, e-mail:
> > dev-help@openoffice.apache.org
> > > > >> >>>>>>
> > > > >> >>>>>>
> > > > >> >>>>>>
> > > > >> >>>>
> > ------------------------------**------------------------------**
> > > > >> >>>> ---------
> > > > >> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**
> > apache.org<
> > > > >> dev-unsubscribe@openoffice.apache.org>
> > > > >> >>>> For additional commands, e-mail:
> > dev-help@openoffice.apache.org
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>
> > > > >> >>
> > > > >>
> > > >
> > ------------------------------**------------------------------**---------
> > > > >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**
> apache.org<
> > > > >> dev-unsubscribe@openoffice.apache.org>
> > > > >> >> For additional commands, e-mail:
> dev-help@openoffice.apache.org
> > > > >> >>
> > > > >> >>
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > > > >> For additional commands, e-mail: dev-help@openoffice.apache.org
> > > > >>
> > > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > > > For additional commands, e-mail: dev-help@openoffice.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> >
> ----------------------------------------------------------------------------------------
> > MzK
> >
> > "You can't believe one thing and do another.
> > What you believe and what you do are the same thing."
> > -- Leonard Peltier
> >
>
--
----------------------------------------------------------------------------------------
MzK
"You can't believe one thing and do another.
What you believe and what you do are the same thing."
-- Leonard Peltier
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 5 June 2013 18:37, Kay Schenk <ka...@gmail.com> wrote:
> On Wed, Jun 5, 2013 at 8:50 AM, janI <ja...@apache.org> wrote:
>
> > On 5 June 2013 17:43, Rob Weir <ro...@apache.org> wrote:
> >
> > > On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
> > > > On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
> > > >
> > > >> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
> > > >> > On 5 June 2013 11:05, Oliver-Rainer Wittmann <
> > > orwittmann@googlemail.com
> > > >> >wrote:
> > > >> >
> > > >> >> Hi,
> > > >> >>
> > > >> >> sorry for top-posting, but I think it makes sense to clean up
> some
> > > >> things.
> > > >> >>
> > > >> >> Some facts and my opinions:
> > > >> >> (1)
> > > >> >> Fact: In communication with infra, infra had proposed
> > > >> >> https://updates.openoffice.**org/ <
> https://updates.openoffice.org/
> > >
> > > (
> > > >> >> https://ooo-updates.**openoffice.org/<
> > > >> https://ooo-updates.openoffice.org/>as the backup) as the URL for
> the
> > > >> resources accessed by the update
> > > >> >> functionality by AOO 4.0 and later. Nobody objects.
> > > >> >> My opinion: I think we should go for it.
> > > >> >>
> > > >> > +1, I will check dns, add whats missing, and when the cert arrives
> > > update
> > > >> > erebus-ssl (the https: proxy)
> > > >> >
> > > >> >>
> > > >> >> (2)
> > > >> >> Fact: In communication with infra, infra had proposed
> > > >> >> ^/openoffice/updates-site/**trunk as the SVN location for the
> > > resources
> > > >> >> needed for the update functionality by AOO 4.0 and later.
> > > >> >> My opinion: I believe it would be good to have the update
> resources
> > > >> >> separated from the website resources. It would mean to move
> > > >> >>
> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update
> > > to
> > > >> >> ^/openoffice/updates-site/**trunk/aoo40/check.Update
> > > >> >>
> > > >> > +1 No problem, I can create the path in svn and add an alias
> (link)
> > in
> > > >> the
> > > >> > httpd server. Btw this is easy to change later, it is a simple one
> > > line,
> > > >> in
> > > >> > the configuration.
> > > >> >
> > > >> >
> > > >> >>
> > > >> >> (3)
> > > >> >> My understanding: I think infra had in mind to "map"
> > > >> >> https://updates.openoffice.org (resp. https://ooo-updates.**
> > > >> >> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
> > > >> >> ^/openoffice/updates-site/**trunk
> > > >> >> Please correct me, if my understanding is not correct.
> > > >> >>
> > > >> > it was correct, but changed to (2)
> > > >> >
> > > >> >>
> > > >> >> (4)
> > > >> >> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo
> > 3.2.1
> > > >> and
> > > >> >> OOo 3.2 will remain at their current SVN location and will be
> > > accessed
> > > >> by
> > > >> >> the current UpdateURLs.
> > > >> >> My opinion: Thus, I believe there will be no change to the SVN
> > > >> locations,
> > > >> >> to the URLs and to the "URL mapping/forwarding" (sorry, I do not
> > know
> > > >> the
> > > >> >> correct term here) for the update resources used by already
> > released
> > > >> >> versions.
> > > >> >>
> > > >> > mapping is the correct term. There will be no changes apart from
> (1)
> > > and
> > > >> > (2)
> > > >> >
> > > >> >>
> > > >> >>
> > > >> >> My proposal:
> > > >> >> I propose to follow infra's proposal mentioned above in (1) and
> > (2).
> > > >> >>
> > > >> > I have added it to infra tasks. We are currently waiting for the
> > cert
> > > to
> > > >> be
> > > >> > sent, then the first step will be to get https: working for wiki
> and
> > > >> > forums, second step is updates.o.o
> > > >> >
> > > >> >>
> > > >> >>
> > > >> >> Best regards, Oliver.
> > > >> >
> > > >> > thx for a very clear mail, if nobody objects within the next 72
> > > hours,
> > > >> it
> > > >> > will be implemented as you propose.
> > > >> >
> > > >>
> > > >> An extra step will be needed. Presumably we want the Apache CMS
> > > >> enabled so it publishes files from the SVN dir to the website dir.
> > > >> This doesn't happen automatically.
> > > >>
> > > >
> > > > that is not only an extra step, that can turn out to be a bigger
> > > challenge.
> > > > Having CMS enabled
> > > > is a very valid request, but then please choose a location inside the
> > > > web-site where CMS is already enabled.
> > > >
> > >
> > > We already have two separate CMS publish targets from our SVN: /site
> > > (openoffice.apache.org) and /ooo-site (www.openoffice.org). Having a
> > > third one should not be a problem. I'd like to avoid the complexity
> > > that would occur if we had the same SVN dir connected to two different
> > > CMS targets.
> > >
> >
> > of course it can be done its software, its just more work and more admin
> > afterward.
> >
> > You would not have one svn dir connected to two different cms targets if
> > target dir is inside www.openoffice.org (which is what I suggested).
> >
> > updates.openoffice.org is logically just a pointer, and would normally
> > point inside the www domain (that is the simple solution), but can point
> > outside the www domain (which requires changes to httpd.conf, and an
> extra
> > cms setup).
> >
>
> from Oliver's commmunication [1], it seems that updates.openoffice.org has
> been suggested to be *outside* the current web site domain, and followed by
> his comments --
>
> "My opinion: I believe it would be good to have the update resources
> separated from the website resources. It would mean to move
> ^/openoffice/ooo-site/trunk/content/projects/aoo40/check.Update to
> ^/openoffice/updates-site/trunk/aoo40/check.Update"
>
> I feel we should NOT point the new update to any area within the existing
> www domain (we had some BIG problems initially trying to enable updates
> through the web server), so a new CMS would be needed. Hopefully, this is
> not a horrendous task.
>
Of course I will not cause big problems, but why does
- ^/openoffice/ooo-site/trunk/**
>
> content/projects/update/**aoo341/ used by
> UpdateURL http://www.openoffice.org/**projects/update/aoo341/check.**
work, while a new aoo40 along the same lines cause big problems ?
the URL is just an alias/mapping to the location inside the tree (or if you
prefer a shortcut notation), it is not a special httpd or anything.
rgds
jan I.
>
>
>
> > rgds
> > jan I.
> >
> >
> > >
> > > -Rob
> > >
> > >
> > > > rgds
> > > > jan i.
> > > >
> > > >>
> > > >> -Rob
> > > >>
> > > >>
> > > >> > rgds
> > > >> > jan I.
> > > >> >
> > > >> >
> > > >> >>
> > > >> >> On 05.06.2013 00:22, janI wrote:
> > > >> >>
> > > >> >>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
> > > >> >>>
> > > >> >>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
> > > >> >>>>
> > > >> >>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org>
> > > wrote:
> > > >> >>>>>
> > > >> >>>>> On 03/06/2013 Rob Weir wrote:
> > > >> >>>>>>
> > > >> >>>>>> I think the concern is this:
> > > >> >>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
> > > >> >>>>>>>
> > > >> >>>>>> http://update.openoffice.org> is not HTTPS.
> > > >> >>>>
> > > >> >>>>>
> > > >> >>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
> > > >> http://apache.org>
> > > >> >>>>>>> <
> > > >> >>>>>>>
> > > >> >>>>>> https://ooo-site.openoffice.**apache.org<
> > > >> https://ooo-site.openoffice.apache.org>>
> > > >> >>>> supports SSL, but is
> > > >> >>>>
> > > >> >>>>> not considered "long term stable". The URL is an artifact of
> > the
> > > CMS
> > > >> >>>>>>> 3) We're looking for a stable URL. One could be
> > > >> >>>>>>> https://updates.openoffice.org****, but that requires an
> SSL
> > > cert
> > > >> for
> > > >> >>>>>>> *.openoffice.org. But will that be supported in time for
> the
> > > AOO
> > > >> 4.0
> > > >> >>>>>>> release?
> > > >> >>>>>>> 4) Backup plan is updates.openoffice.apache.org, which
> could
> > be
> > > >> >>>>>>> supported via SSL today, using the *.apache.org cert. If
> we
> > do
> > > >> that
> > > >> >>>>>>> we'd want to map that to its own CMS dir in SVN. so it can
> be
> > > >> updated
> > > >> >>>>>>> and published via the CMS.
> > > >> >>>>>>>
> > > >> >>>>>>>
> > > >> >>>>>> This is mostly correct, except the fact (in #2 and #4) that
> the
> > > >> current
> > > >> >>>>>> certificates only support x.apache.org and not
> x.y.apache.org:
> > > so
> > > >> >>>>>> https://ooo-site.apache.org is what is in the sources right
> > now
> > > >> (well,
> > > >> >>>>>> the last time I checked) and https://openoffice-updates.
> **a**
> > > >> pache.org<http://apache.org>
> > > >> >>>>>> <
> > > >> >>>>>>
> > > >> >>>>> https://openoffice-updates.**apache.org<
> > > >> https://openoffice-updates.apache.org>>(or
> > > >> >>>> something like that) should be
> > > >> >>>> used for the backup plan in #4.
> > > >> >>>>
> > > >> >>>>>
> > > >> >>>>>>
> > > >> >>>>> Hi
> > > >> >>>>>
> > > >> >>>>> I am confused, it seem we nearly all agree on
> > > >> >>>>> https://updates.openoffice.**orgbut <
> > > >> https://updates.openoffice.orgbut>not on the directory.
> > > >> >>>>>
> > > >> >>>>> The order for the cert is being processed, when the cert
> arrives
> > > it
> > > >> >>>>> needs
> > > >> >>>>> to be implemented on erebus-sll (our https: proxy), and we
> > (infra)
> > > >> need
> > > >> >>>>>
> > > >> >>>> to
> > > >> >>>>
> > > >> >>>>> do some updates on the aoo servers.
> > > >> >>>>>
> > > >> >>>>> In order to do this work, I need:
> > > >> >>>>>
> > > >> >>>>> 1) which url (e.g. https://updates.openoffice.org**)
> > > >> >>>>> 2) should relate to which directory in svn.
> > > >> >>>>>
> > > >> >>>>> The last mails contains different proposal ranging from dont
> do
> > it
> > > >> for
> > > >> >>>>>
> > > >> >>>> 4.0
> > > >> >>>>
> > > >> >>>>> to different dirs, that is something I cannot implement.
> > > >> >>>>>
> > > >> >>>>> We can also decide to forget it for https:updates.*, but I
> need
> > a
> > > >> single
> > > >> >>>>> decision to be able to implement it.
> > > >> >>>>>
> > > >> >>>>>
> > > >> >>>> Is the cert already here? Or do we have a few weeks to decide?
> > > I'd
> > > >> >>>> say, don't let this decision get in the way of deploying the
> cert
> > > and
> > > >> >>>> enabling it for the website, wikis, forums, etc. The update
> > site
> > > >> >>>> doesn't need to be enabled until shortly before AOO 4.0 is
> > > released.
> > > >> >>>>
> > > >> >>>> We have been promised a free cert, I just checked it is not
> yet
> > in
> > > >> our
> > > >> >>> hands.
> > > >> >>>
> > > >> >>> Wiki and other services with login, will be changed to https: to
> > > >> adhere to
> > > >> >>> asf/infra policy.
> > > >> >>> This will be done on infra initative, and the actual setup will
> be
> > > like
> > > >> >>> other servers in asf.
> > > >> >>>
> > > >> >>> update.o.o can come later, but it will definitively save work if
> > we
> > > do
> > > >> it
> > > >> >>> as one task. Of course if
> > > >> >>> the decision is to postpone after 4.0, it will be 2 tasks.
> > > >> >>>
> > > >> >>>
> > > >> >>>
> > > >> >>>
> > > >> >>>> And depending on when the cert arrives, we might not use it at
> > all
> > > for
> > > >> >>>> 4.0 updates. If it comes too late we'll just use an
> apache.org
> > > >> >>>> address. So we're really waiting for Infra on this, not the
> > other
> > > >> >>>> way around. We need an estimate for when the cert will be
> > > purchased
> > > >> >>>> so we can decide whether or not it will be used for 4.0
> updates.
> > > >> >>>>
> > > >> >>>>
> > > >> >>> As I understand it from the code, the end-user never sees this
> > url,
> > > so
> > > >> why
> > > >> >>> not stick with apache.org ?
> > > >> >>>
> > > >> >>> rgds
> > > >> >>> jan I.
> > > >> >>>
> > > >> >>>
> > > >> >>>> -Rob
> > > >> >>>>
> > > >> >>>>
> > > >> >>>> rgds
> > > >> >>>>> jan I.
> > > >> >>>>>
> > > >> >>>>>
> > > >> >>>>>> Regards,
> > > >> >>>>>> Andrea.
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>>>
> > ------------------------------****----------------------------**
> > > >> >>>> --**---------
> > > >> >>>>
> > > >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**
> > pache.org
> > > <
> > > >> http://apache.org>
> > > >> >>>>>> <
> > > >> >>>>>>
> > > >> >>>>> dev-unsubscribe@openoffice.**apache.org<
> > > >> dev-unsubscribe@openoffice.apache.org>
> > > >> >>>> >
> > > >> >>>>
> > > >> >>>>> For additional commands, e-mail:
> dev-help@openoffice.apache.org
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>
> ------------------------------**------------------------------**
> > > >> >>>> ---------
> > > >> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**
> apache.org<
> > > >> dev-unsubscribe@openoffice.apache.org>
> > > >> >>>> For additional commands, e-mail:
> dev-help@openoffice.apache.org
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>
> > > >> >>>
> > > >> >>
> > > >>
> > >
> ------------------------------**------------------------------**---------
> > > >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> > > >> dev-unsubscribe@openoffice.apache.org>
> > > >> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> > > >> >>
> > > >> >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > > >> For additional commands, e-mail: dev-help@openoffice.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > > For additional commands, e-mail: dev-help@openoffice.apache.org
> > >
> > >
> >
>
>
>
> --
>
> ----------------------------------------------------------------------------------------
> MzK
>
> "You can't believe one thing and do another.
> What you believe and what you do are the same thing."
> -- Leonard Peltier
>
Re: updates.openoffice.org
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Jun 5, 2013 at 8:50 AM, janI <ja...@apache.org> wrote:
> On 5 June 2013 17:43, Rob Weir <ro...@apache.org> wrote:
>
> > On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
> > > On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
> > >
> > >> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
> > >> > On 5 June 2013 11:05, Oliver-Rainer Wittmann <
> > orwittmann@googlemail.com
> > >> >wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> sorry for top-posting, but I think it makes sense to clean up some
> > >> things.
> > >> >>
> > >> >> Some facts and my opinions:
> > >> >> (1)
> > >> >> Fact: In communication with infra, infra had proposed
> > >> >> https://updates.openoffice.**org/ <https://updates.openoffice.org/
> >
> > (
> > >> >> https://ooo-updates.**openoffice.org/<
> > >> https://ooo-updates.openoffice.org/>as the backup) as the URL for the
> > >> resources accessed by the update
> > >> >> functionality by AOO 4.0 and later. Nobody objects.
> > >> >> My opinion: I think we should go for it.
> > >> >>
> > >> > +1, I will check dns, add whats missing, and when the cert arrives
> > update
> > >> > erebus-ssl (the https: proxy)
> > >> >
> > >> >>
> > >> >> (2)
> > >> >> Fact: In communication with infra, infra had proposed
> > >> >> ^/openoffice/updates-site/**trunk as the SVN location for the
> > resources
> > >> >> needed for the update functionality by AOO 4.0 and later.
> > >> >> My opinion: I believe it would be good to have the update resources
> > >> >> separated from the website resources. It would mean to move
> > >> >> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update
> > to
> > >> >> ^/openoffice/updates-site/**trunk/aoo40/check.Update
> > >> >>
> > >> > +1 No problem, I can create the path in svn and add an alias (link)
> in
> > >> the
> > >> > httpd server. Btw this is easy to change later, it is a simple one
> > line,
> > >> in
> > >> > the configuration.
> > >> >
> > >> >
> > >> >>
> > >> >> (3)
> > >> >> My understanding: I think infra had in mind to "map"
> > >> >> https://updates.openoffice.org (resp. https://ooo-updates.**
> > >> >> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
> > >> >> ^/openoffice/updates-site/**trunk
> > >> >> Please correct me, if my understanding is not correct.
> > >> >>
> > >> > it was correct, but changed to (2)
> > >> >
> > >> >>
> > >> >> (4)
> > >> >> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo
> 3.2.1
> > >> and
> > >> >> OOo 3.2 will remain at their current SVN location and will be
> > accessed
> > >> by
> > >> >> the current UpdateURLs.
> > >> >> My opinion: Thus, I believe there will be no change to the SVN
> > >> locations,
> > >> >> to the URLs and to the "URL mapping/forwarding" (sorry, I do not
> know
> > >> the
> > >> >> correct term here) for the update resources used by already
> released
> > >> >> versions.
> > >> >>
> > >> > mapping is the correct term. There will be no changes apart from (1)
> > and
> > >> > (2)
> > >> >
> > >> >>
> > >> >>
> > >> >> My proposal:
> > >> >> I propose to follow infra's proposal mentioned above in (1) and
> (2).
> > >> >>
> > >> > I have added it to infra tasks. We are currently waiting for the
> cert
> > to
> > >> be
> > >> > sent, then the first step will be to get https: working for wiki and
> > >> > forums, second step is updates.o.o
> > >> >
> > >> >>
> > >> >>
> > >> >> Best regards, Oliver.
> > >> >
> > >> > thx for a very clear mail, if nobody objects within the next 72
> > hours,
> > >> it
> > >> > will be implemented as you propose.
> > >> >
> > >>
> > >> An extra step will be needed. Presumably we want the Apache CMS
> > >> enabled so it publishes files from the SVN dir to the website dir.
> > >> This doesn't happen automatically.
> > >>
> > >
> > > that is not only an extra step, that can turn out to be a bigger
> > challenge.
> > > Having CMS enabled
> > > is a very valid request, but then please choose a location inside the
> > > web-site where CMS is already enabled.
> > >
> >
> > We already have two separate CMS publish targets from our SVN: /site
> > (openoffice.apache.org) and /ooo-site (www.openoffice.org). Having a
> > third one should not be a problem. I'd like to avoid the complexity
> > that would occur if we had the same SVN dir connected to two different
> > CMS targets.
> >
>
> of course it can be done its software, its just more work and more admin
> afterward.
>
> You would not have one svn dir connected to two different cms targets if
> target dir is inside www.openoffice.org (which is what I suggested).
>
> updates.openoffice.org is logically just a pointer, and would normally
> point inside the www domain (that is the simple solution), but can point
> outside the www domain (which requires changes to httpd.conf, and an extra
> cms setup).
>
from Oliver's commmunication [1], it seems that updates.openoffice.org has
been suggested to be *outside* the current web site domain, and followed by
his comments --
"My opinion: I believe it would be good to have the update resources
separated from the website resources. It would mean to move
^/openoffice/ooo-site/trunk/content/projects/aoo40/check.Update to
^/openoffice/updates-site/trunk/aoo40/check.Update"
I feel we should NOT point the new update to any area within the existing
www domain (we had some BIG problems initially trying to enable updates
through the web server), so a new CMS would be needed. Hopefully, this is
not a horrendous task.
> rgds
> jan I.
>
>
> >
> > -Rob
> >
> >
> > > rgds
> > > jan i.
> > >
> > >>
> > >> -Rob
> > >>
> > >>
> > >> > rgds
> > >> > jan I.
> > >> >
> > >> >
> > >> >>
> > >> >> On 05.06.2013 00:22, janI wrote:
> > >> >>
> > >> >>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
> > >> >>>
> > >> >>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
> > >> >>>>
> > >> >>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org>
> > wrote:
> > >> >>>>>
> > >> >>>>> On 03/06/2013 Rob Weir wrote:
> > >> >>>>>>
> > >> >>>>>> I think the concern is this:
> > >> >>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
> > >> >>>>>>>
> > >> >>>>>> http://update.openoffice.org> is not HTTPS.
> > >> >>>>
> > >> >>>>>
> > >> >>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
> > >> http://apache.org>
> > >> >>>>>>> <
> > >> >>>>>>>
> > >> >>>>>> https://ooo-site.openoffice.**apache.org<
> > >> https://ooo-site.openoffice.apache.org>>
> > >> >>>> supports SSL, but is
> > >> >>>>
> > >> >>>>> not considered "long term stable". The URL is an artifact of
> the
> > CMS
> > >> >>>>>>> 3) We're looking for a stable URL. One could be
> > >> >>>>>>> https://updates.openoffice.org****, but that requires an SSL
> > cert
> > >> for
> > >> >>>>>>> *.openoffice.org. But will that be supported in time for the
> > AOO
> > >> 4.0
> > >> >>>>>>> release?
> > >> >>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could
> be
> > >> >>>>>>> supported via SSL today, using the *.apache.org cert. If we
> do
> > >> that
> > >> >>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be
> > >> updated
> > >> >>>>>>> and published via the CMS.
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>> This is mostly correct, except the fact (in #2 and #4) that the
> > >> current
> > >> >>>>>> certificates only support x.apache.org and not x.y.apache.org:
> > so
> > >> >>>>>> https://ooo-site.apache.org is what is in the sources right
> now
> > >> (well,
> > >> >>>>>> the last time I checked) and https://openoffice-updates.**a**
> > >> pache.org<http://apache.org>
> > >> >>>>>> <
> > >> >>>>>>
> > >> >>>>> https://openoffice-updates.**apache.org<
> > >> https://openoffice-updates.apache.org>>(or
> > >> >>>> something like that) should be
> > >> >>>> used for the backup plan in #4.
> > >> >>>>
> > >> >>>>>
> > >> >>>>>>
> > >> >>>>> Hi
> > >> >>>>>
> > >> >>>>> I am confused, it seem we nearly all agree on
> > >> >>>>> https://updates.openoffice.**orgbut <
> > >> https://updates.openoffice.orgbut>not on the directory.
> > >> >>>>>
> > >> >>>>> The order for the cert is being processed, when the cert arrives
> > it
> > >> >>>>> needs
> > >> >>>>> to be implemented on erebus-sll (our https: proxy), and we
> (infra)
> > >> need
> > >> >>>>>
> > >> >>>> to
> > >> >>>>
> > >> >>>>> do some updates on the aoo servers.
> > >> >>>>>
> > >> >>>>> In order to do this work, I need:
> > >> >>>>>
> > >> >>>>> 1) which url (e.g. https://updates.openoffice.org**)
> > >> >>>>> 2) should relate to which directory in svn.
> > >> >>>>>
> > >> >>>>> The last mails contains different proposal ranging from dont do
> it
> > >> for
> > >> >>>>>
> > >> >>>> 4.0
> > >> >>>>
> > >> >>>>> to different dirs, that is something I cannot implement.
> > >> >>>>>
> > >> >>>>> We can also decide to forget it for https:updates.*, but I need
> a
> > >> single
> > >> >>>>> decision to be able to implement it.
> > >> >>>>>
> > >> >>>>>
> > >> >>>> Is the cert already here? Or do we have a few weeks to decide?
> > I'd
> > >> >>>> say, don't let this decision get in the way of deploying the cert
> > and
> > >> >>>> enabling it for the website, wikis, forums, etc. The update
> site
> > >> >>>> doesn't need to be enabled until shortly before AOO 4.0 is
> > released.
> > >> >>>>
> > >> >>>> We have been promised a free cert, I just checked it is not yet
> in
> > >> our
> > >> >>> hands.
> > >> >>>
> > >> >>> Wiki and other services with login, will be changed to https: to
> > >> adhere to
> > >> >>> asf/infra policy.
> > >> >>> This will be done on infra initative, and the actual setup will be
> > like
> > >> >>> other servers in asf.
> > >> >>>
> > >> >>> update.o.o can come later, but it will definitively save work if
> we
> > do
> > >> it
> > >> >>> as one task. Of course if
> > >> >>> the decision is to postpone after 4.0, it will be 2 tasks.
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>>> And depending on when the cert arrives, we might not use it at
> all
> > for
> > >> >>>> 4.0 updates. If it comes too late we'll just use an apache.org
> > >> >>>> address. So we're really waiting for Infra on this, not the
> other
> > >> >>>> way around. We need an estimate for when the cert will be
> > purchased
> > >> >>>> so we can decide whether or not it will be used for 4.0 updates.
> > >> >>>>
> > >> >>>>
> > >> >>> As I understand it from the code, the end-user never sees this
> url,
> > so
> > >> why
> > >> >>> not stick with apache.org ?
> > >> >>>
> > >> >>> rgds
> > >> >>> jan I.
> > >> >>>
> > >> >>>
> > >> >>>> -Rob
> > >> >>>>
> > >> >>>>
> > >> >>>> rgds
> > >> >>>>> jan I.
> > >> >>>>>
> > >> >>>>>
> > >> >>>>>> Regards,
> > >> >>>>>> Andrea.
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> ------------------------------****----------------------------**
> > >> >>>> --**---------
> > >> >>>>
> > >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**
> pache.org
> > <
> > >> http://apache.org>
> > >> >>>>>> <
> > >> >>>>>>
> > >> >>>>> dev-unsubscribe@openoffice.**apache.org<
> > >> dev-unsubscribe@openoffice.apache.org>
> > >> >>>> >
> > >> >>>>
> > >> >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>> ------------------------------**------------------------------**
> > >> >>>> ---------
> > >> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> > >> dev-unsubscribe@openoffice.apache.org>
> > >> >>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> > ------------------------------**------------------------------**---------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> > >> dev-unsubscribe@openoffice.apache.org>
> > >> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >> >>
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
--
----------------------------------------------------------------------------------------
MzK
"You can't believe one thing and do another.
What you believe and what you do are the same thing."
-- Leonard Peltier
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 5 June 2013 17:43, Rob Weir <ro...@apache.org> wrote:
> On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
> > On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
> >
> >> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
> >> > On 5 June 2013 11:05, Oliver-Rainer Wittmann <
> orwittmann@googlemail.com
> >> >wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> sorry for top-posting, but I think it makes sense to clean up some
> >> things.
> >> >>
> >> >> Some facts and my opinions:
> >> >> (1)
> >> >> Fact: In communication with infra, infra had proposed
> >> >> https://updates.openoffice.**org/ <https://updates.openoffice.org/>
> (
> >> >> https://ooo-updates.**openoffice.org/<
> >> https://ooo-updates.openoffice.org/>as the backup) as the URL for the
> >> resources accessed by the update
> >> >> functionality by AOO 4.0 and later. Nobody objects.
> >> >> My opinion: I think we should go for it.
> >> >>
> >> > +1, I will check dns, add whats missing, and when the cert arrives
> update
> >> > erebus-ssl (the https: proxy)
> >> >
> >> >>
> >> >> (2)
> >> >> Fact: In communication with infra, infra had proposed
> >> >> ^/openoffice/updates-site/**trunk as the SVN location for the
> resources
> >> >> needed for the update functionality by AOO 4.0 and later.
> >> >> My opinion: I believe it would be good to have the update resources
> >> >> separated from the website resources. It would mean to move
> >> >> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update
> to
> >> >> ^/openoffice/updates-site/**trunk/aoo40/check.Update
> >> >>
> >> > +1 No problem, I can create the path in svn and add an alias (link) in
> >> the
> >> > httpd server. Btw this is easy to change later, it is a simple one
> line,
> >> in
> >> > the configuration.
> >> >
> >> >
> >> >>
> >> >> (3)
> >> >> My understanding: I think infra had in mind to "map"
> >> >> https://updates.openoffice.org (resp. https://ooo-updates.**
> >> >> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
> >> >> ^/openoffice/updates-site/**trunk
> >> >> Please correct me, if my understanding is not correct.
> >> >>
> >> > it was correct, but changed to (2)
> >> >
> >> >>
> >> >> (4)
> >> >> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo 3.2.1
> >> and
> >> >> OOo 3.2 will remain at their current SVN location and will be
> accessed
> >> by
> >> >> the current UpdateURLs.
> >> >> My opinion: Thus, I believe there will be no change to the SVN
> >> locations,
> >> >> to the URLs and to the "URL mapping/forwarding" (sorry, I do not know
> >> the
> >> >> correct term here) for the update resources used by already released
> >> >> versions.
> >> >>
> >> > mapping is the correct term. There will be no changes apart from (1)
> and
> >> > (2)
> >> >
> >> >>
> >> >>
> >> >> My proposal:
> >> >> I propose to follow infra's proposal mentioned above in (1) and (2).
> >> >>
> >> > I have added it to infra tasks. We are currently waiting for the cert
> to
> >> be
> >> > sent, then the first step will be to get https: working for wiki and
> >> > forums, second step is updates.o.o
> >> >
> >> >>
> >> >>
> >> >> Best regards, Oliver.
> >> >
> >> > thx for a very clear mail, if nobody objects within the next 72
> hours,
> >> it
> >> > will be implemented as you propose.
> >> >
> >>
> >> An extra step will be needed. Presumably we want the Apache CMS
> >> enabled so it publishes files from the SVN dir to the website dir.
> >> This doesn't happen automatically.
> >>
> >
> > that is not only an extra step, that can turn out to be a bigger
> challenge.
> > Having CMS enabled
> > is a very valid request, but then please choose a location inside the
> > web-site where CMS is already enabled.
> >
>
> We already have two separate CMS publish targets from our SVN: /site
> (openoffice.apache.org) and /ooo-site (www.openoffice.org). Having a
> third one should not be a problem. I'd like to avoid the complexity
> that would occur if we had the same SVN dir connected to two different
> CMS targets.
>
of course it can be done its software, its just more work and more admin
afterward.
You would not have one svn dir connected to two different cms targets if
target dir is inside www.openoffice.org (which is what I suggested).
updates.openoffice.org is logically just a pointer, and would normally
point inside the www domain (that is the simple solution), but can point
outside the www domain (which requires changes to httpd.conf, and an extra
cms setup).
rgds
jan I.
>
> -Rob
>
>
> > rgds
> > jan i.
> >
> >>
> >> -Rob
> >>
> >>
> >> > rgds
> >> > jan I.
> >> >
> >> >
> >> >>
> >> >> On 05.06.2013 00:22, janI wrote:
> >> >>
> >> >>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
> >> >>>
> >> >>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
> >> >>>>
> >> >>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org>
> wrote:
> >> >>>>>
> >> >>>>> On 03/06/2013 Rob Weir wrote:
> >> >>>>>>
> >> >>>>>> I think the concern is this:
> >> >>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
> >> >>>>>>>
> >> >>>>>> http://update.openoffice.org> is not HTTPS.
> >> >>>>
> >> >>>>>
> >> >>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
> >> http://apache.org>
> >> >>>>>>> <
> >> >>>>>>>
> >> >>>>>> https://ooo-site.openoffice.**apache.org<
> >> https://ooo-site.openoffice.apache.org>>
> >> >>>> supports SSL, but is
> >> >>>>
> >> >>>>> not considered "long term stable". The URL is an artifact of the
> CMS
> >> >>>>>>> 3) We're looking for a stable URL. One could be
> >> >>>>>>> https://updates.openoffice.org****, but that requires an SSL
> cert
> >> for
> >> >>>>>>> *.openoffice.org. But will that be supported in time for the
> AOO
> >> 4.0
> >> >>>>>>> release?
> >> >>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could be
> >> >>>>>>> supported via SSL today, using the *.apache.org cert. If we do
> >> that
> >> >>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be
> >> updated
> >> >>>>>>> and published via the CMS.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> This is mostly correct, except the fact (in #2 and #4) that the
> >> current
> >> >>>>>> certificates only support x.apache.org and not x.y.apache.org:
> so
> >> >>>>>> https://ooo-site.apache.org is what is in the sources right now
> >> (well,
> >> >>>>>> the last time I checked) and https://openoffice-updates.**a**
> >> pache.org<http://apache.org>
> >> >>>>>> <
> >> >>>>>>
> >> >>>>> https://openoffice-updates.**apache.org<
> >> https://openoffice-updates.apache.org>>(or
> >> >>>> something like that) should be
> >> >>>> used for the backup plan in #4.
> >> >>>>
> >> >>>>>
> >> >>>>>>
> >> >>>>> Hi
> >> >>>>>
> >> >>>>> I am confused, it seem we nearly all agree on
> >> >>>>> https://updates.openoffice.**orgbut <
> >> https://updates.openoffice.orgbut>not on the directory.
> >> >>>>>
> >> >>>>> The order for the cert is being processed, when the cert arrives
> it
> >> >>>>> needs
> >> >>>>> to be implemented on erebus-sll (our https: proxy), and we (infra)
> >> need
> >> >>>>>
> >> >>>> to
> >> >>>>
> >> >>>>> do some updates on the aoo servers.
> >> >>>>>
> >> >>>>> In order to do this work, I need:
> >> >>>>>
> >> >>>>> 1) which url (e.g. https://updates.openoffice.org**)
> >> >>>>> 2) should relate to which directory in svn.
> >> >>>>>
> >> >>>>> The last mails contains different proposal ranging from dont do it
> >> for
> >> >>>>>
> >> >>>> 4.0
> >> >>>>
> >> >>>>> to different dirs, that is something I cannot implement.
> >> >>>>>
> >> >>>>> We can also decide to forget it for https:updates.*, but I need a
> >> single
> >> >>>>> decision to be able to implement it.
> >> >>>>>
> >> >>>>>
> >> >>>> Is the cert already here? Or do we have a few weeks to decide?
> I'd
> >> >>>> say, don't let this decision get in the way of deploying the cert
> and
> >> >>>> enabling it for the website, wikis, forums, etc. The update site
> >> >>>> doesn't need to be enabled until shortly before AOO 4.0 is
> released.
> >> >>>>
> >> >>>> We have been promised a free cert, I just checked it is not yet in
> >> our
> >> >>> hands.
> >> >>>
> >> >>> Wiki and other services with login, will be changed to https: to
> >> adhere to
> >> >>> asf/infra policy.
> >> >>> This will be done on infra initative, and the actual setup will be
> like
> >> >>> other servers in asf.
> >> >>>
> >> >>> update.o.o can come later, but it will definitively save work if we
> do
> >> it
> >> >>> as one task. Of course if
> >> >>> the decision is to postpone after 4.0, it will be 2 tasks.
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>> And depending on when the cert arrives, we might not use it at all
> for
> >> >>>> 4.0 updates. If it comes too late we'll just use an apache.org
> >> >>>> address. So we're really waiting for Infra on this, not the other
> >> >>>> way around. We need an estimate for when the cert will be
> purchased
> >> >>>> so we can decide whether or not it will be used for 4.0 updates.
> >> >>>>
> >> >>>>
> >> >>> As I understand it from the code, the end-user never sees this url,
> so
> >> why
> >> >>> not stick with apache.org ?
> >> >>>
> >> >>> rgds
> >> >>> jan I.
> >> >>>
> >> >>>
> >> >>>> -Rob
> >> >>>>
> >> >>>>
> >> >>>> rgds
> >> >>>>> jan I.
> >> >>>>>
> >> >>>>>
> >> >>>>>> Regards,
> >> >>>>>> Andrea.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> ------------------------------****----------------------------**
> >> >>>> --**---------
> >> >>>>
> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**pache.org
> <
> >> http://apache.org>
> >> >>>>>> <
> >> >>>>>>
> >> >>>>> dev-unsubscribe@openoffice.**apache.org<
> >> dev-unsubscribe@openoffice.apache.org>
> >> >>>> >
> >> >>>>
> >> >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>> ------------------------------**------------------------------**
> >> >>>> ---------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> >> dev-unsubscribe@openoffice.apache.org>
> >> >>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> ------------------------------**------------------------------**---------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> >> dev-unsubscribe@openoffice.apache.org>
> >> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: updates.openoffice.org
Posted by Rob Weir <ro...@apache.org>.
On Wed, Jun 5, 2013 at 11:34 AM, janI <ja...@apache.org> wrote:
> On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
>
>> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
>> > On 5 June 2013 11:05, Oliver-Rainer Wittmann <orwittmann@googlemail.com
>> >wrote:
>> >
>> >> Hi,
>> >>
>> >> sorry for top-posting, but I think it makes sense to clean up some
>> things.
>> >>
>> >> Some facts and my opinions:
>> >> (1)
>> >> Fact: In communication with infra, infra had proposed
>> >> https://updates.openoffice.**org/ <https://updates.openoffice.org/> (
>> >> https://ooo-updates.**openoffice.org/<
>> https://ooo-updates.openoffice.org/>as the backup) as the URL for the
>> resources accessed by the update
>> >> functionality by AOO 4.0 and later. Nobody objects.
>> >> My opinion: I think we should go for it.
>> >>
>> > +1, I will check dns, add whats missing, and when the cert arrives update
>> > erebus-ssl (the https: proxy)
>> >
>> >>
>> >> (2)
>> >> Fact: In communication with infra, infra had proposed
>> >> ^/openoffice/updates-site/**trunk as the SVN location for the resources
>> >> needed for the update functionality by AOO 4.0 and later.
>> >> My opinion: I believe it would be good to have the update resources
>> >> separated from the website resources. It would mean to move
>> >> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update to
>> >> ^/openoffice/updates-site/**trunk/aoo40/check.Update
>> >>
>> > +1 No problem, I can create the path in svn and add an alias (link) in
>> the
>> > httpd server. Btw this is easy to change later, it is a simple one line,
>> in
>> > the configuration.
>> >
>> >
>> >>
>> >> (3)
>> >> My understanding: I think infra had in mind to "map"
>> >> https://updates.openoffice.org (resp. https://ooo-updates.**
>> >> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
>> >> ^/openoffice/updates-site/**trunk
>> >> Please correct me, if my understanding is not correct.
>> >>
>> > it was correct, but changed to (2)
>> >
>> >>
>> >> (4)
>> >> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo 3.2.1
>> and
>> >> OOo 3.2 will remain at their current SVN location and will be accessed
>> by
>> >> the current UpdateURLs.
>> >> My opinion: Thus, I believe there will be no change to the SVN
>> locations,
>> >> to the URLs and to the "URL mapping/forwarding" (sorry, I do not know
>> the
>> >> correct term here) for the update resources used by already released
>> >> versions.
>> >>
>> > mapping is the correct term. There will be no changes apart from (1) and
>> > (2)
>> >
>> >>
>> >>
>> >> My proposal:
>> >> I propose to follow infra's proposal mentioned above in (1) and (2).
>> >>
>> > I have added it to infra tasks. We are currently waiting for the cert to
>> be
>> > sent, then the first step will be to get https: working for wiki and
>> > forums, second step is updates.o.o
>> >
>> >>
>> >>
>> >> Best regards, Oliver.
>> >
>> > thx for a very clear mail, if nobody objects within the next 72 hours,
>> it
>> > will be implemented as you propose.
>> >
>>
>> An extra step will be needed. Presumably we want the Apache CMS
>> enabled so it publishes files from the SVN dir to the website dir.
>> This doesn't happen automatically.
>>
>
> that is not only an extra step, that can turn out to be a bigger challenge.
> Having CMS enabled
> is a very valid request, but then please choose a location inside the
> web-site where CMS is already enabled.
>
We already have two separate CMS publish targets from our SVN: /site
(openoffice.apache.org) and /ooo-site (www.openoffice.org). Having a
third one should not be a problem. I'd like to avoid the complexity
that would occur if we had the same SVN dir connected to two different
CMS targets.
-Rob
> rgds
> jan i.
>
>>
>> -Rob
>>
>>
>> > rgds
>> > jan I.
>> >
>> >
>> >>
>> >> On 05.06.2013 00:22, janI wrote:
>> >>
>> >>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
>> >>>
>> >>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
>> >>>>
>> >>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
>> >>>>>
>> >>>>> On 03/06/2013 Rob Weir wrote:
>> >>>>>>
>> >>>>>> I think the concern is this:
>> >>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
>> >>>>>>>
>> >>>>>> http://update.openoffice.org> is not HTTPS.
>> >>>>
>> >>>>>
>> >>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
>> http://apache.org>
>> >>>>>>> <
>> >>>>>>>
>> >>>>>> https://ooo-site.openoffice.**apache.org<
>> https://ooo-site.openoffice.apache.org>>
>> >>>> supports SSL, but is
>> >>>>
>> >>>>> not considered "long term stable". The URL is an artifact of the CMS
>> >>>>>>> 3) We're looking for a stable URL. One could be
>> >>>>>>> https://updates.openoffice.org****, but that requires an SSL cert
>> for
>> >>>>>>> *.openoffice.org. But will that be supported in time for the AOO
>> 4.0
>> >>>>>>> release?
>> >>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could be
>> >>>>>>> supported via SSL today, using the *.apache.org cert. If we do
>> that
>> >>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be
>> updated
>> >>>>>>> and published via the CMS.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> This is mostly correct, except the fact (in #2 and #4) that the
>> current
>> >>>>>> certificates only support x.apache.org and not x.y.apache.org: so
>> >>>>>> https://ooo-site.apache.org is what is in the sources right now
>> (well,
>> >>>>>> the last time I checked) and https://openoffice-updates.**a**
>> pache.org<http://apache.org>
>> >>>>>> <
>> >>>>>>
>> >>>>> https://openoffice-updates.**apache.org<
>> https://openoffice-updates.apache.org>>(or
>> >>>> something like that) should be
>> >>>> used for the backup plan in #4.
>> >>>>
>> >>>>>
>> >>>>>>
>> >>>>> Hi
>> >>>>>
>> >>>>> I am confused, it seem we nearly all agree on
>> >>>>> https://updates.openoffice.**orgbut <
>> https://updates.openoffice.orgbut>not on the directory.
>> >>>>>
>> >>>>> The order for the cert is being processed, when the cert arrives it
>> >>>>> needs
>> >>>>> to be implemented on erebus-sll (our https: proxy), and we (infra)
>> need
>> >>>>>
>> >>>> to
>> >>>>
>> >>>>> do some updates on the aoo servers.
>> >>>>>
>> >>>>> In order to do this work, I need:
>> >>>>>
>> >>>>> 1) which url (e.g. https://updates.openoffice.org**)
>> >>>>> 2) should relate to which directory in svn.
>> >>>>>
>> >>>>> The last mails contains different proposal ranging from dont do it
>> for
>> >>>>>
>> >>>> 4.0
>> >>>>
>> >>>>> to different dirs, that is something I cannot implement.
>> >>>>>
>> >>>>> We can also decide to forget it for https:updates.*, but I need a
>> single
>> >>>>> decision to be able to implement it.
>> >>>>>
>> >>>>>
>> >>>> Is the cert already here? Or do we have a few weeks to decide? I'd
>> >>>> say, don't let this decision get in the way of deploying the cert and
>> >>>> enabling it for the website, wikis, forums, etc. The update site
>> >>>> doesn't need to be enabled until shortly before AOO 4.0 is released.
>> >>>>
>> >>>> We have been promised a free cert, I just checked it is not yet in
>> our
>> >>> hands.
>> >>>
>> >>> Wiki and other services with login, will be changed to https: to
>> adhere to
>> >>> asf/infra policy.
>> >>> This will be done on infra initative, and the actual setup will be like
>> >>> other servers in asf.
>> >>>
>> >>> update.o.o can come later, but it will definitively save work if we do
>> it
>> >>> as one task. Of course if
>> >>> the decision is to postpone after 4.0, it will be 2 tasks.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>> And depending on when the cert arrives, we might not use it at all for
>> >>>> 4.0 updates. If it comes too late we'll just use an apache.org
>> >>>> address. So we're really waiting for Infra on this, not the other
>> >>>> way around. We need an estimate for when the cert will be purchased
>> >>>> so we can decide whether or not it will be used for 4.0 updates.
>> >>>>
>> >>>>
>> >>> As I understand it from the code, the end-user never sees this url, so
>> why
>> >>> not stick with apache.org ?
>> >>>
>> >>> rgds
>> >>> jan I.
>> >>>
>> >>>
>> >>>> -Rob
>> >>>>
>> >>>>
>> >>>> rgds
>> >>>>> jan I.
>> >>>>>
>> >>>>>
>> >>>>>> Regards,
>> >>>>>> Andrea.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> ------------------------------****----------------------------**
>> >>>> --**---------
>> >>>>
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**pache.org<
>> http://apache.org>
>> >>>>>> <
>> >>>>>>
>> >>>>> dev-unsubscribe@openoffice.**apache.org<
>> dev-unsubscribe@openoffice.apache.org>
>> >>>> >
>> >>>>
>> >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>> ------------------------------**------------------------------**
>> >>>> ---------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> dev-unsubscribe@openoffice.apache.org>
>> >>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> ------------------------------**------------------------------**---------
>> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> dev-unsubscribe@openoffice.apache.org>
>> >> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 5 June 2013 16:48, Rob Weir <ro...@apache.org> wrote:
> On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
> > On 5 June 2013 11:05, Oliver-Rainer Wittmann <orwittmann@googlemail.com
> >wrote:
> >
> >> Hi,
> >>
> >> sorry for top-posting, but I think it makes sense to clean up some
> things.
> >>
> >> Some facts and my opinions:
> >> (1)
> >> Fact: In communication with infra, infra had proposed
> >> https://updates.openoffice.**org/ <https://updates.openoffice.org/> (
> >> https://ooo-updates.**openoffice.org/<
> https://ooo-updates.openoffice.org/>as the backup) as the URL for the
> resources accessed by the update
> >> functionality by AOO 4.0 and later. Nobody objects.
> >> My opinion: I think we should go for it.
> >>
> > +1, I will check dns, add whats missing, and when the cert arrives update
> > erebus-ssl (the https: proxy)
> >
> >>
> >> (2)
> >> Fact: In communication with infra, infra had proposed
> >> ^/openoffice/updates-site/**trunk as the SVN location for the resources
> >> needed for the update functionality by AOO 4.0 and later.
> >> My opinion: I believe it would be good to have the update resources
> >> separated from the website resources. It would mean to move
> >> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update to
> >> ^/openoffice/updates-site/**trunk/aoo40/check.Update
> >>
> > +1 No problem, I can create the path in svn and add an alias (link) in
> the
> > httpd server. Btw this is easy to change later, it is a simple one line,
> in
> > the configuration.
> >
> >
> >>
> >> (3)
> >> My understanding: I think infra had in mind to "map"
> >> https://updates.openoffice.org (resp. https://ooo-updates.**
> >> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
> >> ^/openoffice/updates-site/**trunk
> >> Please correct me, if my understanding is not correct.
> >>
> > it was correct, but changed to (2)
> >
> >>
> >> (4)
> >> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo 3.2.1
> and
> >> OOo 3.2 will remain at their current SVN location and will be accessed
> by
> >> the current UpdateURLs.
> >> My opinion: Thus, I believe there will be no change to the SVN
> locations,
> >> to the URLs and to the "URL mapping/forwarding" (sorry, I do not know
> the
> >> correct term here) for the update resources used by already released
> >> versions.
> >>
> > mapping is the correct term. There will be no changes apart from (1) and
> > (2)
> >
> >>
> >>
> >> My proposal:
> >> I propose to follow infra's proposal mentioned above in (1) and (2).
> >>
> > I have added it to infra tasks. We are currently waiting for the cert to
> be
> > sent, then the first step will be to get https: working for wiki and
> > forums, second step is updates.o.o
> >
> >>
> >>
> >> Best regards, Oliver.
> >
> > thx for a very clear mail, if nobody objects within the next 72 hours,
> it
> > will be implemented as you propose.
> >
>
> An extra step will be needed. Presumably we want the Apache CMS
> enabled so it publishes files from the SVN dir to the website dir.
> This doesn't happen automatically.
>
that is not only an extra step, that can turn out to be a bigger challenge.
Having CMS enabled
is a very valid request, but then please choose a location inside the
web-site where CMS is already enabled.
rgds
jan i.
>
> -Rob
>
>
> > rgds
> > jan I.
> >
> >
> >>
> >> On 05.06.2013 00:22, janI wrote:
> >>
> >>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
> >>>
> >>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
> >>>>
> >>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
> >>>>>
> >>>>> On 03/06/2013 Rob Weir wrote:
> >>>>>>
> >>>>>> I think the concern is this:
> >>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
> >>>>>>>
> >>>>>> http://update.openoffice.org> is not HTTPS.
> >>>>
> >>>>>
> >>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<
> http://apache.org>
> >>>>>>> <
> >>>>>>>
> >>>>>> https://ooo-site.openoffice.**apache.org<
> https://ooo-site.openoffice.apache.org>>
> >>>> supports SSL, but is
> >>>>
> >>>>> not considered "long term stable". The URL is an artifact of the CMS
> >>>>>>> 3) We're looking for a stable URL. One could be
> >>>>>>> https://updates.openoffice.org****, but that requires an SSL cert
> for
> >>>>>>> *.openoffice.org. But will that be supported in time for the AOO
> 4.0
> >>>>>>> release?
> >>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could be
> >>>>>>> supported via SSL today, using the *.apache.org cert. If we do
> that
> >>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be
> updated
> >>>>>>> and published via the CMS.
> >>>>>>>
> >>>>>>>
> >>>>>> This is mostly correct, except the fact (in #2 and #4) that the
> current
> >>>>>> certificates only support x.apache.org and not x.y.apache.org: so
> >>>>>> https://ooo-site.apache.org is what is in the sources right now
> (well,
> >>>>>> the last time I checked) and https://openoffice-updates.**a**
> pache.org<http://apache.org>
> >>>>>> <
> >>>>>>
> >>>>> https://openoffice-updates.**apache.org<
> https://openoffice-updates.apache.org>>(or
> >>>> something like that) should be
> >>>> used for the backup plan in #4.
> >>>>
> >>>>>
> >>>>>>
> >>>>> Hi
> >>>>>
> >>>>> I am confused, it seem we nearly all agree on
> >>>>> https://updates.openoffice.**orgbut <
> https://updates.openoffice.orgbut>not on the directory.
> >>>>>
> >>>>> The order for the cert is being processed, when the cert arrives it
> >>>>> needs
> >>>>> to be implemented on erebus-sll (our https: proxy), and we (infra)
> need
> >>>>>
> >>>> to
> >>>>
> >>>>> do some updates on the aoo servers.
> >>>>>
> >>>>> In order to do this work, I need:
> >>>>>
> >>>>> 1) which url (e.g. https://updates.openoffice.org**)
> >>>>> 2) should relate to which directory in svn.
> >>>>>
> >>>>> The last mails contains different proposal ranging from dont do it
> for
> >>>>>
> >>>> 4.0
> >>>>
> >>>>> to different dirs, that is something I cannot implement.
> >>>>>
> >>>>> We can also decide to forget it for https:updates.*, but I need a
> single
> >>>>> decision to be able to implement it.
> >>>>>
> >>>>>
> >>>> Is the cert already here? Or do we have a few weeks to decide? I'd
> >>>> say, don't let this decision get in the way of deploying the cert and
> >>>> enabling it for the website, wikis, forums, etc. The update site
> >>>> doesn't need to be enabled until shortly before AOO 4.0 is released.
> >>>>
> >>>> We have been promised a free cert, I just checked it is not yet in
> our
> >>> hands.
> >>>
> >>> Wiki and other services with login, will be changed to https: to
> adhere to
> >>> asf/infra policy.
> >>> This will be done on infra initative, and the actual setup will be like
> >>> other servers in asf.
> >>>
> >>> update.o.o can come later, but it will definitively save work if we do
> it
> >>> as one task. Of course if
> >>> the decision is to postpone after 4.0, it will be 2 tasks.
> >>>
> >>>
> >>>
> >>>
> >>>> And depending on when the cert arrives, we might not use it at all for
> >>>> 4.0 updates. If it comes too late we'll just use an apache.org
> >>>> address. So we're really waiting for Infra on this, not the other
> >>>> way around. We need an estimate for when the cert will be purchased
> >>>> so we can decide whether or not it will be used for 4.0 updates.
> >>>>
> >>>>
> >>> As I understand it from the code, the end-user never sees this url, so
> why
> >>> not stick with apache.org ?
> >>>
> >>> rgds
> >>> jan I.
> >>>
> >>>
> >>>> -Rob
> >>>>
> >>>>
> >>>> rgds
> >>>>> jan I.
> >>>>>
> >>>>>
> >>>>>> Regards,
> >>>>>> Andrea.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------****----------------------------**
> >>>> --**---------
> >>>>
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**pache.org<
> http://apache.org>
> >>>>>> <
> >>>>>>
> >>>>> dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscribe@openoffice.apache.org>
> >>>> >
> >>>>
> >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> ------------------------------**------------------------------**
> >>>> ---------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscribe@openoffice.apache.org>
> >>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscribe@openoffice.apache.org>
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: updates.openoffice.org
Posted by Rob Weir <ro...@apache.org>.
On Wed, Jun 5, 2013 at 10:32 AM, janI <ja...@apache.org> wrote:
> On 5 June 2013 11:05, Oliver-Rainer Wittmann <or...@googlemail.com>wrote:
>
>> Hi,
>>
>> sorry for top-posting, but I think it makes sense to clean up some things.
>>
>> Some facts and my opinions:
>> (1)
>> Fact: In communication with infra, infra had proposed
>> https://updates.openoffice.**org/ <https://updates.openoffice.org/> (
>> https://ooo-updates.**openoffice.org/<https://ooo-updates.openoffice.org/>as the backup) as the URL for the resources accessed by the update
>> functionality by AOO 4.0 and later. Nobody objects.
>> My opinion: I think we should go for it.
>>
> +1, I will check dns, add whats missing, and when the cert arrives update
> erebus-ssl (the https: proxy)
>
>>
>> (2)
>> Fact: In communication with infra, infra had proposed
>> ^/openoffice/updates-site/**trunk as the SVN location for the resources
>> needed for the update functionality by AOO 4.0 and later.
>> My opinion: I believe it would be good to have the update resources
>> separated from the website resources. It would mean to move
>> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update to
>> ^/openoffice/updates-site/**trunk/aoo40/check.Update
>>
> +1 No problem, I can create the path in svn and add an alias (link) in the
> httpd server. Btw this is easy to change later, it is a simple one line, in
> the configuration.
>
>
>>
>> (3)
>> My understanding: I think infra had in mind to "map"
>> https://updates.openoffice.org (resp. https://ooo-updates.**
>> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
>> ^/openoffice/updates-site/**trunk
>> Please correct me, if my understanding is not correct.
>>
> it was correct, but changed to (2)
>
>>
>> (4)
>> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo 3.2.1 and
>> OOo 3.2 will remain at their current SVN location and will be accessed by
>> the current UpdateURLs.
>> My opinion: Thus, I believe there will be no change to the SVN locations,
>> to the URLs and to the "URL mapping/forwarding" (sorry, I do not know the
>> correct term here) for the update resources used by already released
>> versions.
>>
> mapping is the correct term. There will be no changes apart from (1) and
> (2)
>
>>
>>
>> My proposal:
>> I propose to follow infra's proposal mentioned above in (1) and (2).
>>
> I have added it to infra tasks. We are currently waiting for the cert to be
> sent, then the first step will be to get https: working for wiki and
> forums, second step is updates.o.o
>
>>
>>
>> Best regards, Oliver.
>
> thx for a very clear mail, if nobody objects within the next 72 hours, it
> will be implemented as you propose.
>
An extra step will be needed. Presumably we want the Apache CMS
enabled so it publishes files from the SVN dir to the website dir.
This doesn't happen automatically.
-Rob
> rgds
> jan I.
>
>
>>
>> On 05.06.2013 00:22, janI wrote:
>>
>>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
>>>
>>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
>>>>
>>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
>>>>>
>>>>> On 03/06/2013 Rob Weir wrote:
>>>>>>
>>>>>> I think the concern is this:
>>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
>>>>>>>
>>>>>> http://update.openoffice.org> is not HTTPS.
>>>>
>>>>>
>>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<http://apache.org>
>>>>>>> <
>>>>>>>
>>>>>> https://ooo-site.openoffice.**apache.org<https://ooo-site.openoffice.apache.org>>
>>>> supports SSL, but is
>>>>
>>>>> not considered "long term stable". The URL is an artifact of the CMS
>>>>>>> 3) We're looking for a stable URL. One could be
>>>>>>> https://updates.openoffice.org****, but that requires an SSL cert for
>>>>>>> *.openoffice.org. But will that be supported in time for the AOO 4.0
>>>>>>> release?
>>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could be
>>>>>>> supported via SSL today, using the *.apache.org cert. If we do that
>>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be updated
>>>>>>> and published via the CMS.
>>>>>>>
>>>>>>>
>>>>>> This is mostly correct, except the fact (in #2 and #4) that the current
>>>>>> certificates only support x.apache.org and not x.y.apache.org: so
>>>>>> https://ooo-site.apache.org is what is in the sources right now (well,
>>>>>> the last time I checked) and https://openoffice-updates.**a**pache.org<http://apache.org>
>>>>>> <
>>>>>>
>>>>> https://openoffice-updates.**apache.org<https://openoffice-updates.apache.org>>(or
>>>> something like that) should be
>>>> used for the backup plan in #4.
>>>>
>>>>>
>>>>>>
>>>>> Hi
>>>>>
>>>>> I am confused, it seem we nearly all agree on
>>>>> https://updates.openoffice.**orgbut <https://updates.openoffice.orgbut>not on the directory.
>>>>>
>>>>> The order for the cert is being processed, when the cert arrives it
>>>>> needs
>>>>> to be implemented on erebus-sll (our https: proxy), and we (infra) need
>>>>>
>>>> to
>>>>
>>>>> do some updates on the aoo servers.
>>>>>
>>>>> In order to do this work, I need:
>>>>>
>>>>> 1) which url (e.g. https://updates.openoffice.org**)
>>>>> 2) should relate to which directory in svn.
>>>>>
>>>>> The last mails contains different proposal ranging from dont do it for
>>>>>
>>>> 4.0
>>>>
>>>>> to different dirs, that is something I cannot implement.
>>>>>
>>>>> We can also decide to forget it for https:updates.*, but I need a single
>>>>> decision to be able to implement it.
>>>>>
>>>>>
>>>> Is the cert already here? Or do we have a few weeks to decide? I'd
>>>> say, don't let this decision get in the way of deploying the cert and
>>>> enabling it for the website, wikis, forums, etc. The update site
>>>> doesn't need to be enabled until shortly before AOO 4.0 is released.
>>>>
>>>> We have been promised a free cert, I just checked it is not yet in our
>>> hands.
>>>
>>> Wiki and other services with login, will be changed to https: to adhere to
>>> asf/infra policy.
>>> This will be done on infra initative, and the actual setup will be like
>>> other servers in asf.
>>>
>>> update.o.o can come later, but it will definitively save work if we do it
>>> as one task. Of course if
>>> the decision is to postpone after 4.0, it will be 2 tasks.
>>>
>>>
>>>
>>>
>>>> And depending on when the cert arrives, we might not use it at all for
>>>> 4.0 updates. If it comes too late we'll just use an apache.org
>>>> address. So we're really waiting for Infra on this, not the other
>>>> way around. We need an estimate for when the cert will be purchased
>>>> so we can decide whether or not it will be used for 4.0 updates.
>>>>
>>>>
>>> As I understand it from the code, the end-user never sees this url, so why
>>> not stick with apache.org ?
>>>
>>> rgds
>>> jan I.
>>>
>>>
>>>> -Rob
>>>>
>>>>
>>>> rgds
>>>>> jan I.
>>>>>
>>>>>
>>>>>> Regards,
>>>>>> Andrea.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**pache.org<http://apache.org>
>>>>>> <
>>>>>>
>>>>> dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>>>> >
>>>>
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 5 June 2013 11:05, Oliver-Rainer Wittmann <or...@googlemail.com>wrote:
> Hi,
>
> sorry for top-posting, but I think it makes sense to clean up some things.
>
> Some facts and my opinions:
> (1)
> Fact: In communication with infra, infra had proposed
> https://updates.openoffice.**org/ <https://updates.openoffice.org/> (
> https://ooo-updates.**openoffice.org/<https://ooo-updates.openoffice.org/>as the backup) as the URL for the resources accessed by the update
> functionality by AOO 4.0 and later. Nobody objects.
> My opinion: I think we should go for it.
>
+1, I will check dns, add whats missing, and when the cert arrives update
erebus-ssl (the https: proxy)
>
> (2)
> Fact: In communication with infra, infra had proposed
> ^/openoffice/updates-site/**trunk as the SVN location for the resources
> needed for the update functionality by AOO 4.0 and later.
> My opinion: I believe it would be good to have the update resources
> separated from the website resources. It would mean to move
> ^/openoffice/ooo-site/trunk/**content/projects/aoo40/check.**Update to
> ^/openoffice/updates-site/**trunk/aoo40/check.Update
>
+1 No problem, I can create the path in svn and add an alias (link) in the
httpd server. Btw this is easy to change later, it is a simple one line, in
the configuration.
>
> (3)
> My understanding: I think infra had in mind to "map"
> https://updates.openoffice.org (resp. https://ooo-updates.**
> openoffice.org/ <https://ooo-updates.openoffice.org/>) to
> ^/openoffice/updates-site/**trunk
> Please correct me, if my understanding is not correct.
>
it was correct, but changed to (2)
>
> (4)
> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo 3.2.1 and
> OOo 3.2 will remain at their current SVN location and will be accessed by
> the current UpdateURLs.
> My opinion: Thus, I believe there will be no change to the SVN locations,
> to the URLs and to the "URL mapping/forwarding" (sorry, I do not know the
> correct term here) for the update resources used by already released
> versions.
>
mapping is the correct term. There will be no changes apart from (1) and
(2)
>
>
> My proposal:
> I propose to follow infra's proposal mentioned above in (1) and (2).
>
I have added it to infra tasks. We are currently waiting for the cert to be
sent, then the first step will be to get https: working for wiki and
forums, second step is updates.o.o
>
>
> Best regards, Oliver.
thx for a very clear mail, if nobody objects within the next 72 hours, it
will be implemented as you propose.
rgds
jan I.
>
> On 05.06.2013 00:22, janI wrote:
>
>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
>>
>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
>>>
>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
>>>>
>>>> On 03/06/2013 Rob Weir wrote:
>>>>>
>>>>> I think the concern is this:
>>>>>> 1) We want SSL for 4.0.http://update.openoffice.****org<
>>>>>>
>>>>> http://update.openoffice.org> is not HTTPS.
>>>
>>>>
>>>>>> 2) The URL https://ooo-site.openoffice.****apache.org<http://apache.org>
>>>>>> <
>>>>>>
>>>>> https://ooo-site.openoffice.**apache.org<https://ooo-site.openoffice.apache.org>>
>>> supports SSL, but is
>>>
>>>> not considered "long term stable". The URL is an artifact of the CMS
>>>>>> 3) We're looking for a stable URL. One could be
>>>>>> https://updates.openoffice.org****, but that requires an SSL cert for
>>>>>> *.openoffice.org. But will that be supported in time for the AOO 4.0
>>>>>> release?
>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could be
>>>>>> supported via SSL today, using the *.apache.org cert. If we do that
>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be updated
>>>>>> and published via the CMS.
>>>>>>
>>>>>>
>>>>> This is mostly correct, except the fact (in #2 and #4) that the current
>>>>> certificates only support x.apache.org and not x.y.apache.org: so
>>>>> https://ooo-site.apache.org is what is in the sources right now (well,
>>>>> the last time I checked) and https://openoffice-updates.**a**pache.org<http://apache.org>
>>>>> <
>>>>>
>>>> https://openoffice-updates.**apache.org<https://openoffice-updates.apache.org>>(or
>>> something like that) should be
>>> used for the backup plan in #4.
>>>
>>>>
>>>>>
>>>> Hi
>>>>
>>>> I am confused, it seem we nearly all agree on
>>>> https://updates.openoffice.**orgbut <https://updates.openoffice.orgbut>not on the directory.
>>>>
>>>> The order for the cert is being processed, when the cert arrives it
>>>> needs
>>>> to be implemented on erebus-sll (our https: proxy), and we (infra) need
>>>>
>>> to
>>>
>>>> do some updates on the aoo servers.
>>>>
>>>> In order to do this work, I need:
>>>>
>>>> 1) which url (e.g. https://updates.openoffice.org**)
>>>> 2) should relate to which directory in svn.
>>>>
>>>> The last mails contains different proposal ranging from dont do it for
>>>>
>>> 4.0
>>>
>>>> to different dirs, that is something I cannot implement.
>>>>
>>>> We can also decide to forget it for https:updates.*, but I need a single
>>>> decision to be able to implement it.
>>>>
>>>>
>>> Is the cert already here? Or do we have a few weeks to decide? I'd
>>> say, don't let this decision get in the way of deploying the cert and
>>> enabling it for the website, wikis, forums, etc. The update site
>>> doesn't need to be enabled until shortly before AOO 4.0 is released.
>>>
>>> We have been promised a free cert, I just checked it is not yet in our
>> hands.
>>
>> Wiki and other services with login, will be changed to https: to adhere to
>> asf/infra policy.
>> This will be done on infra initative, and the actual setup will be like
>> other servers in asf.
>>
>> update.o.o can come later, but it will definitively save work if we do it
>> as one task. Of course if
>> the decision is to postpone after 4.0, it will be 2 tasks.
>>
>>
>>
>>
>>> And depending on when the cert arrives, we might not use it at all for
>>> 4.0 updates. If it comes too late we'll just use an apache.org
>>> address. So we're really waiting for Infra on this, not the other
>>> way around. We need an estimate for when the cert will be purchased
>>> so we can decide whether or not it will be used for 4.0 updates.
>>>
>>>
>> As I understand it from the code, the end-user never sees this url, so why
>> not stick with apache.org ?
>>
>> rgds
>> jan I.
>>
>>
>>> -Rob
>>>
>>>
>>> rgds
>>>> jan I.
>>>>
>>>>
>>>>> Regards,
>>>>> Andrea.
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>> --**---------
>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**pache.org<http://apache.org>
>>>>> <
>>>>>
>>>> dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>>> >
>>>
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>>>
>>>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: updates.openoffice.org
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
damn - I just noticed that I have given the wrong fallback URL.
It must be https://ooo-updates.apache.org/
instead of https://ooo-updates.openoffice.org/
Best regards, Oliver.
On 05.06.2013 11:05, Oliver-Rainer Wittmann wrote:
> Hi,
>
> sorry for top-posting, but I think it makes sense to clean up some things.
>
> Some facts and my opinions:
> (1)
> Fact: In communication with infra, infra had proposed
> https://updates.openoffice.org/ (https://ooo-updates.openoffice.org/ as
> the backup) as the URL for the resources accessed by the update
> functionality by AOO 4.0 and later. Nobody objects.
> My opinion: I think we should go for it.
>
> (2)
> Fact: In communication with infra, infra had proposed
> ^/openoffice/updates-site/trunk as the SVN location for the resources
> needed for the update functionality by AOO 4.0 and later.
> My opinion: I believe it would be good to have the update resources
> separated from the website resources. It would mean to move
> ^/openoffice/ooo-site/trunk/content/projects/aoo40/check.Update to
> ^/openoffice/updates-site/trunk/aoo40/check.Update
>
> (3)
> My understanding: I think infra had in mind to "map"
> https://updates.openoffice.org (resp.
> https://ooo-updates.openoffice.org/) to ^/openoffice/updates-site/trunk
> Please correct me, if my understanding is not correct.
>
> (4)
> Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo 3.2.1
> and OOo 3.2 will remain at their current SVN location and will be
> accessed by the current UpdateURLs.
> My opinion: Thus, I believe there will be no change to the SVN
> locations, to the URLs and to the "URL mapping/forwarding" (sorry, I do
> not know the correct term here) for the update resources used by already
> released versions.
>
>
> My proposal:
> I propose to follow infra's proposal mentioned above in (1) and (2).
>
>
> Best regards, Oliver.
>
> On 05.06.2013 00:22, janI wrote:
>> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
>>
>>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
>>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
>>>>
>>>>> On 03/06/2013 Rob Weir wrote:
>>>>>
>>>>>> I think the concern is this:
>>>>>> 1) We want SSL for 4.0.http://update.openoffice.**org<
>>> http://update.openoffice.org> is not HTTPS.
>>>>>>
>>>>>> 2) The URL https://ooo-site.openoffice.**apache.org<
>>> https://ooo-site.openoffice.apache.org> supports SSL, but is
>>>>>> not considered "long term stable". The URL is an artifact of the CMS
>>>>>> 3) We're looking for a stable URL. One could be
>>>>>> https://updates.openoffice.org**, but that requires an SSL cert for
>>>>>> *.openoffice.org. But will that be supported in time for the AOO 4.0
>>>>>> release?
>>>>>> 4) Backup plan is updates.openoffice.apache.org, which could be
>>>>>> supported via SSL today, using the *.apache.org cert. If we do that
>>>>>> we'd want to map that to its own CMS dir in SVN. so it can be updated
>>>>>> and published via the CMS.
>>>>>>
>>>>>
>>>>> This is mostly correct, except the fact (in #2 and #4) that the
>>>>> current
>>>>> certificates only support x.apache.org and not x.y.apache.org: so
>>>>> https://ooo-site.apache.org is what is in the sources right now (well,
>>>>> the last time I checked) and https://openoffice-updates.**apache.org<
>>> https://openoffice-updates.apache.org>(or something like that) should be
>>> used for the backup plan in #4.
>>>>>
>>>>
>>>> Hi
>>>>
>>>> I am confused, it seem we nearly all agree on
>>>> https://updates.openoffice.orgbut not on the directory.
>>>>
>>>> The order for the cert is being processed, when the cert arrives it
>>>> needs
>>>> to be implemented on erebus-sll (our https: proxy), and we (infra) need
>>> to
>>>> do some updates on the aoo servers.
>>>>
>>>> In order to do this work, I need:
>>>>
>>>> 1) which url (e.g. https://updates.openoffice.org)
>>>> 2) should relate to which directory in svn.
>>>>
>>>> The last mails contains different proposal ranging from dont do it for
>>> 4.0
>>>> to different dirs, that is something I cannot implement.
>>>>
>>>> We can also decide to forget it for https:updates.*, but I need a
>>>> single
>>>> decision to be able to implement it.
>>>>
>>>
>>> Is the cert already here? Or do we have a few weeks to decide? I'd
>>> say, don't let this decision get in the way of deploying the cert and
>>> enabling it for the website, wikis, forums, etc. The update site
>>> doesn't need to be enabled until shortly before AOO 4.0 is released.
>>>
>> We have been promised a free cert, I just checked it is not yet in our
>> hands.
>>
>> Wiki and other services with login, will be changed to https: to
>> adhere to
>> asf/infra policy.
>> This will be done on infra initative, and the actual setup will be like
>> other servers in asf.
>>
>> update.o.o can come later, but it will definitively save work if we do it
>> as one task. Of course if
>> the decision is to postpone after 4.0, it will be 2 tasks.
>>
>>
>>
>>>
>>> And depending on when the cert arrives, we might not use it at all for
>>> 4.0 updates. If it comes too late we'll just use an apache.org
>>> address. So we're really waiting for Infra on this, not the other
>>> way around. We need an estimate for when the cert will be purchased
>>> so we can decide whether or not it will be used for 4.0 updates.
>>>
>>
>> As I understand it from the code, the end-user never sees this url, so
>> why
>> not stick with apache.org ?
>>
>> rgds
>> jan I.
>>
>>>
>>> -Rob
>>>
>>>
>>>> rgds
>>>> jan I.
>>>>
>>>>>
>>>>> Regards,
>>>>> Andrea.
>>>>>
>>>>>
>>>>>
>>> ------------------------------**------------------------------**---------
>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>>> dev-unsubscribe@openoffice.apache.org>
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
sorry for top-posting, but I think it makes sense to clean up some things.
Some facts and my opinions:
(1)
Fact: In communication with infra, infra had proposed
https://updates.openoffice.org/ (https://ooo-updates.openoffice.org/ as
the backup) as the URL for the resources accessed by the update
functionality by AOO 4.0 and later. Nobody objects.
My opinion: I think we should go for it.
(2)
Fact: In communication with infra, infra had proposed
^/openoffice/updates-site/trunk as the SVN location for the resources
needed for the update functionality by AOO 4.0 and later.
My opinion: I believe it would be good to have the update resources
separated from the website resources. It would mean to move
^/openoffice/ooo-site/trunk/content/projects/aoo40/check.Update to
^/openoffice/updates-site/trunk/aoo40/check.Update
(3)
My understanding: I think infra had in mind to "map"
https://updates.openoffice.org (resp.
https://ooo-updates.openoffice.org/) to ^/openoffice/updates-site/trunk
Please correct me, if my understanding is not correct.
(4)
Fact: The update resources for AOO 3.4.1, AOO 3.4, OOo 3.3, OOo 3.2.1
and OOo 3.2 will remain at their current SVN location and will be
accessed by the current UpdateURLs.
My opinion: Thus, I believe there will be no change to the SVN
locations, to the URLs and to the "URL mapping/forwarding" (sorry, I do
not know the correct term here) for the update resources used by already
released versions.
My proposal:
I propose to follow infra's proposal mentioned above in (1) and (2).
Best regards, Oliver.
On 05.06.2013 00:22, janI wrote:
> On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
>
>> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
>>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
>>>
>>>> On 03/06/2013 Rob Weir wrote:
>>>>
>>>>> I think the concern is this:
>>>>> 1) We want SSL for 4.0.http://update.openoffice.**org<
>> http://update.openoffice.org> is not HTTPS.
>>>>>
>>>>> 2) The URL https://ooo-site.openoffice.**apache.org<
>> https://ooo-site.openoffice.apache.org> supports SSL, but is
>>>>> not considered "long term stable". The URL is an artifact of the CMS
>>>>> 3) We're looking for a stable URL. One could be
>>>>> https://updates.openoffice.org**, but that requires an SSL cert for
>>>>> *.openoffice.org. But will that be supported in time for the AOO 4.0
>>>>> release?
>>>>> 4) Backup plan is updates.openoffice.apache.org, which could be
>>>>> supported via SSL today, using the *.apache.org cert. If we do that
>>>>> we'd want to map that to its own CMS dir in SVN. so it can be updated
>>>>> and published via the CMS.
>>>>>
>>>>
>>>> This is mostly correct, except the fact (in #2 and #4) that the current
>>>> certificates only support x.apache.org and not x.y.apache.org: so
>>>> https://ooo-site.apache.org is what is in the sources right now (well,
>>>> the last time I checked) and https://openoffice-updates.**apache.org<
>> https://openoffice-updates.apache.org>(or something like that) should be
>> used for the backup plan in #4.
>>>>
>>>
>>> Hi
>>>
>>> I am confused, it seem we nearly all agree on
>>> https://updates.openoffice.orgbut not on the directory.
>>>
>>> The order for the cert is being processed, when the cert arrives it needs
>>> to be implemented on erebus-sll (our https: proxy), and we (infra) need
>> to
>>> do some updates on the aoo servers.
>>>
>>> In order to do this work, I need:
>>>
>>> 1) which url (e.g. https://updates.openoffice.org)
>>> 2) should relate to which directory in svn.
>>>
>>> The last mails contains different proposal ranging from dont do it for
>> 4.0
>>> to different dirs, that is something I cannot implement.
>>>
>>> We can also decide to forget it for https:updates.*, but I need a single
>>> decision to be able to implement it.
>>>
>>
>> Is the cert already here? Or do we have a few weeks to decide? I'd
>> say, don't let this decision get in the way of deploying the cert and
>> enabling it for the website, wikis, forums, etc. The update site
>> doesn't need to be enabled until shortly before AOO 4.0 is released.
>>
> We have been promised a free cert, I just checked it is not yet in our
> hands.
>
> Wiki and other services with login, will be changed to https: to adhere to
> asf/infra policy.
> This will be done on infra initative, and the actual setup will be like
> other servers in asf.
>
> update.o.o can come later, but it will definitively save work if we do it
> as one task. Of course if
> the decision is to postpone after 4.0, it will be 2 tasks.
>
>
>
>>
>> And depending on when the cert arrives, we might not use it at all for
>> 4.0 updates. If it comes too late we'll just use an apache.org
>> address. So we're really waiting for Infra on this, not the other
>> way around. We need an estimate for when the cert will be purchased
>> so we can decide whether or not it will be used for 4.0 updates.
>>
>
> As I understand it from the code, the end-user never sees this url, so why
> not stick with apache.org ?
>
> rgds
> jan I.
>
>>
>> -Rob
>>
>>
>>> rgds
>>> jan I.
>>>
>>>>
>>>> Regards,
>>>> Andrea.
>>>>
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> dev-unsubscribe@openoffice.apache.org>
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 5 June 2013 00:05, Rob Weir <ro...@apache.org> wrote:
> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
> > On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
> >
> >> On 03/06/2013 Rob Weir wrote:
> >>
> >>> I think the concern is this:
> >>> 1) We want SSL for 4.0.http://update.openoffice.**org<
> http://update.openoffice.org> is not HTTPS.
> >>>
> >>> 2) The URL https://ooo-site.openoffice.**apache.org<
> https://ooo-site.openoffice.apache.org> supports SSL, but is
> >>> not considered "long term stable". The URL is an artifact of the CMS
> >>> 3) We're looking for a stable URL. One could be
> >>> https://updates.openoffice.org**, but that requires an SSL cert for
> >>> *.openoffice.org. But will that be supported in time for the AOO 4.0
> >>> release?
> >>> 4) Backup plan is updates.openoffice.apache.org, which could be
> >>> supported via SSL today, using the *.apache.org cert. If we do that
> >>> we'd want to map that to its own CMS dir in SVN. so it can be updated
> >>> and published via the CMS.
> >>>
> >>
> >> This is mostly correct, except the fact (in #2 and #4) that the current
> >> certificates only support x.apache.org and not x.y.apache.org: so
> >> https://ooo-site.apache.org is what is in the sources right now (well,
> >> the last time I checked) and https://openoffice-updates.**apache.org<
> https://openoffice-updates.apache.org>(or something like that) should be
> used for the backup plan in #4.
> >>
> >
> > Hi
> >
> > I am confused, it seem we nearly all agree on
> > https://updates.openoffice.orgbut not on the directory.
> >
> > The order for the cert is being processed, when the cert arrives it needs
> > to be implemented on erebus-sll (our https: proxy), and we (infra) need
> to
> > do some updates on the aoo servers.
> >
> > In order to do this work, I need:
> >
> > 1) which url (e.g. https://updates.openoffice.org)
> > 2) should relate to which directory in svn.
> >
> > The last mails contains different proposal ranging from dont do it for
> 4.0
> > to different dirs, that is something I cannot implement.
> >
> > We can also decide to forget it for https:updates.*, but I need a single
> > decision to be able to implement it.
> >
>
> Is the cert already here? Or do we have a few weeks to decide? I'd
> say, don't let this decision get in the way of deploying the cert and
> enabling it for the website, wikis, forums, etc. The update site
> doesn't need to be enabled until shortly before AOO 4.0 is released.
>
We have been promised a free cert, I just checked it is not yet in our
hands.
Wiki and other services with login, will be changed to https: to adhere to
asf/infra policy.
This will be done on infra initative, and the actual setup will be like
other servers in asf.
update.o.o can come later, but it will definitively save work if we do it
as one task. Of course if
the decision is to postpone after 4.0, it will be 2 tasks.
>
> And depending on when the cert arrives, we might not use it at all for
> 4.0 updates. If it comes too late we'll just use an apache.org
> address. So we're really waiting for Infra on this, not the other
> way around. We need an estimate for when the cert will be purchased
> so we can decide whether or not it will be used for 4.0 updates.
>
As I understand it from the code, the end-user never sees this url, so why
not stick with apache.org ?
rgds
jan I.
>
> -Rob
>
>
> > rgds
> > jan I.
> >
> >>
> >> Regards,
> >> Andrea.
> >>
> >>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscribe@openoffice.apache.org>
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: updates.openoffice.org
Posted by Rob Weir <ro...@apache.org>.
I should mention also that we have a BZ issue tracking this required
change. It is categorized as a Release Blocker, so we don't forget
it:
https://issues.apache.org/ooo/show_bug.cgi?id=122444
-Rob
On Tue, Jun 4, 2013 at 6:05 PM, Rob Weir <ro...@apache.org> wrote:
> On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
>> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
>>
>>> On 03/06/2013 Rob Weir wrote:
>>>
>>>> I think the concern is this:
>>>> 1) We want SSL for 4.0.http://update.openoffice.**org<http://update.openoffice.org> is not HTTPS.
>>>>
>>>> 2) The URL https://ooo-site.openoffice.**apache.org<https://ooo-site.openoffice.apache.org> supports SSL, but is
>>>> not considered "long term stable". The URL is an artifact of the CMS
>>>> 3) We're looking for a stable URL. One could be
>>>> https://updates.openoffice.org**, but that requires an SSL cert for
>>>> *.openoffice.org. But will that be supported in time for the AOO 4.0
>>>> release?
>>>> 4) Backup plan is updates.openoffice.apache.org, which could be
>>>> supported via SSL today, using the *.apache.org cert. If we do that
>>>> we'd want to map that to its own CMS dir in SVN. so it can be updated
>>>> and published via the CMS.
>>>>
>>>
>>> This is mostly correct, except the fact (in #2 and #4) that the current
>>> certificates only support x.apache.org and not x.y.apache.org: so
>>> https://ooo-site.apache.org is what is in the sources right now (well,
>>> the last time I checked) and https://openoffice-updates.**apache.org<https://openoffice-updates.apache.org>(or something like that) should be used for the backup plan in #4.
>>>
>>
>> Hi
>>
>> I am confused, it seem we nearly all agree on
>> https://updates.openoffice.orgbut not on the directory.
>>
>> The order for the cert is being processed, when the cert arrives it needs
>> to be implemented on erebus-sll (our https: proxy), and we (infra) need to
>> do some updates on the aoo servers.
>>
>> In order to do this work, I need:
>>
>> 1) which url (e.g. https://updates.openoffice.org)
>> 2) should relate to which directory in svn.
>>
>> The last mails contains different proposal ranging from dont do it for 4.0
>> to different dirs, that is something I cannot implement.
>>
>> We can also decide to forget it for https:updates.*, but I need a single
>> decision to be able to implement it.
>>
>
> Is the cert already here? Or do we have a few weeks to decide? I'd
> say, don't let this decision get in the way of deploying the cert and
> enabling it for the website, wikis, forums, etc. The update site
> doesn't need to be enabled until shortly before AOO 4.0 is released.
>
> And depending on when the cert arrives, we might not use it at all for
> 4.0 updates. If it comes too late we'll just use an apache.org
> address. So we're really waiting for Infra on this, not the other
> way around. We need an estimate for when the cert will be purchased
> so we can decide whether or not it will be used for 4.0 updates.
>
> -Rob
>
>
>> rgds
>> jan I.
>>
>>>
>>> Regards,
>>> Andrea.
>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jun 4, 2013 at 5:59 PM, janI <ja...@apache.org> wrote:
> On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
>
>> On 03/06/2013 Rob Weir wrote:
>>
>>> I think the concern is this:
>>> 1) We want SSL for 4.0.http://update.openoffice.**org<http://update.openoffice.org> is not HTTPS.
>>>
>>> 2) The URL https://ooo-site.openoffice.**apache.org<https://ooo-site.openoffice.apache.org> supports SSL, but is
>>> not considered "long term stable". The URL is an artifact of the CMS
>>> 3) We're looking for a stable URL. One could be
>>> https://updates.openoffice.org**, but that requires an SSL cert for
>>> *.openoffice.org. But will that be supported in time for the AOO 4.0
>>> release?
>>> 4) Backup plan is updates.openoffice.apache.org, which could be
>>> supported via SSL today, using the *.apache.org cert. If we do that
>>> we'd want to map that to its own CMS dir in SVN. so it can be updated
>>> and published via the CMS.
>>>
>>
>> This is mostly correct, except the fact (in #2 and #4) that the current
>> certificates only support x.apache.org and not x.y.apache.org: so
>> https://ooo-site.apache.org is what is in the sources right now (well,
>> the last time I checked) and https://openoffice-updates.**apache.org<https://openoffice-updates.apache.org>(or something like that) should be used for the backup plan in #4.
>>
>
> Hi
>
> I am confused, it seem we nearly all agree on
> https://updates.openoffice.orgbut not on the directory.
>
> The order for the cert is being processed, when the cert arrives it needs
> to be implemented on erebus-sll (our https: proxy), and we (infra) need to
> do some updates on the aoo servers.
>
> In order to do this work, I need:
>
> 1) which url (e.g. https://updates.openoffice.org)
> 2) should relate to which directory in svn.
>
> The last mails contains different proposal ranging from dont do it for 4.0
> to different dirs, that is something I cannot implement.
>
> We can also decide to forget it for https:updates.*, but I need a single
> decision to be able to implement it.
>
Is the cert already here? Or do we have a few weeks to decide? I'd
say, don't let this decision get in the way of deploying the cert and
enabling it for the website, wikis, forums, etc. The update site
doesn't need to be enabled until shortly before AOO 4.0 is released.
And depending on when the cert arrives, we might not use it at all for
4.0 updates. If it comes too late we'll just use an apache.org
address. So we're really waiting for Infra on this, not the other
way around. We need an estimate for when the cert will be purchased
so we can decide whether or not it will be used for 4.0 updates.
-Rob
> rgds
> jan I.
>
>>
>> Regards,
>> Andrea.
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 4 June 2013 22:36, Andrea Pescetti <pe...@apache.org> wrote:
> On 03/06/2013 Rob Weir wrote:
>
>> I think the concern is this:
>> 1) We want SSL for 4.0.http://update.openoffice.**org<http://update.openoffice.org> is not HTTPS.
>>
>> 2) The URL https://ooo-site.openoffice.**apache.org<https://ooo-site.openoffice.apache.org> supports SSL, but is
>> not considered "long term stable". The URL is an artifact of the CMS
>> 3) We're looking for a stable URL. One could be
>> https://updates.openoffice.org**, but that requires an SSL cert for
>> *.openoffice.org. But will that be supported in time for the AOO 4.0
>> release?
>> 4) Backup plan is updates.openoffice.apache.org, which could be
>> supported via SSL today, using the *.apache.org cert. If we do that
>> we'd want to map that to its own CMS dir in SVN. so it can be updated
>> and published via the CMS.
>>
>
> This is mostly correct, except the fact (in #2 and #4) that the current
> certificates only support x.apache.org and not x.y.apache.org: so
> https://ooo-site.apache.org is what is in the sources right now (well,
> the last time I checked) and https://openoffice-updates.**apache.org<https://openoffice-updates.apache.org>(or something like that) should be used for the backup plan in #4.
>
Hi
I am confused, it seem we nearly all agree on
https://updates.openoffice.orgbut not on the directory.
The order for the cert is being processed, when the cert arrives it needs
to be implemented on erebus-sll (our https: proxy), and we (infra) need to
do some updates on the aoo servers.
In order to do this work, I need:
1) which url (e.g. https://updates.openoffice.org)
2) should relate to which directory in svn.
The last mails contains different proposal ranging from dont do it for 4.0
to different dirs, that is something I cannot implement.
We can also decide to forget it for https:updates.*, but I need a single
decision to be able to implement it.
rgds
jan I.
>
> Regards,
> Andrea.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: updates.openoffice.org
Posted by Andrea Pescetti <pe...@apache.org>.
On 03/06/2013 Rob Weir wrote:
> I think the concern is this:
> 1) We want SSL for 4.0.http://update.openoffice.org is not HTTPS.
> 2) The URL https://ooo-site.openoffice.apache.org supports SSL, but is
> not considered "long term stable". The URL is an artifact of the CMS
> 3) We're looking for a stable URL. One could be
> https://updates.openoffice.org, but that requires an SSL cert for
> *.openoffice.org. But will that be supported in time for the AOO 4.0
> release?
> 4) Backup plan is updates.openoffice.apache.org, which could be
> supported via SSL today, using the *.apache.org cert. If we do that
> we'd want to map that to its own CMS dir in SVN. so it can be updated
> and published via the CMS.
This is mostly correct, except the fact (in #2 and #4) that the current
certificates only support x.apache.org and not x.y.apache.org: so
https://ooo-site.apache.org is what is in the sources right now (well,
the last time I checked) and https://openoffice-updates.apache.org (or
something like that) should be used for the backup plan in #4.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jun 3, 2013 at 8:11 AM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi,
>
>
> On 03.06.2013 13:50, janI wrote:
>>
>> On 3 June 2013 11:43, Oliver-Rainer Wittmann
>> <or...@googlemail.com>wrote:
>>
>>> Hi,
>>>
>>> On 02.06.2013 16:43, janI wrote:
>>>
>>>> Hi.
>>>>
>>>> I have asked by my infra collegaues, to ensuere we (AOO) have consensus
>>>> on
>>>> how to handle updates.openoffice.org
>>>>
>>>> I nobody objects I will assume lazy consensus in 72 hours from now and
>>>>
>>>> 1) create trunk/ooo-site/upates
>>>>
>>>
>>> My understandings of the communication with infra is that
>>> ^/openoffice/updates-site/**trunk/
>>> should be created for holding the needed application update data for AOO
>>> 4.0 and later.
>>>
>>> I am not sure, if my understanding is correct.
>>> Thus, please let us clarify it.
>>>
>>>
>>> Just for your information - the locations for the released versions are:
>>> - ^/openoffice/ooo-site/trunk/**content/projects/update/**aoo341/ used by
>>> UpdateURL http://www.openoffice.org/**projects/update/aoo341/check.**
>>> Update <http://www.openoffice.org/projects/update/aoo341/check.Update>for
>>> AOO 3.4.1
>>> - ^/openoffice/ooo-site/trunk/**content/projects/update38/ used by
>>> UpdateURL http://update38.services.**openoffice.org/**
>>>
>>> ProductUpdateService/check.**Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>for
>>> AOO 3.4
>>> - ^/openoffice/ooo-site/trunk/**content/projects/update36/ used by
>>> UpdateURL http://update36.services.**openoffice.org/**
>>>
>>> ProductUpdateService/check.**Update<http://update36.services.openoffice.org/ProductUpdateService/check.Update>for
>>> OOo 3.3
>>> - ^/openoffice/ooo-site/trunk/**content/projects/update35/ used by
>>> UpdateURL http://update35.services.**openoffice.org/**
>>>
>>> ProductUpdateService/check.**Update<http://update35.services.openoffice.org/ProductUpdateService/check.Update>for
>>> OOo 3.2.1
>>> - ^/openoffice/ooo-site/trunk/**content/projects/update34/ used by
>>> UpdateURL http://update34.services.**openoffice.org/**
>>>
>>> ProductUpdateService/check.**Update<http://update34.services.openoffice.org/ProductUpdateService/check.Update>for
>>> OOo 3.2
>>>
>>
>> Using that we should make
>> ^/openoffice/ooo-site/trunk/content/projects/update40/
>> and have updates.o.o point at that.
>
>
> We have already ^/openoffice/ooo-site/trunk/content/projects/aoo40/ for
> current AOO 4.0 trunk builds - as stated in the communication with infra.
>
> I am currently very confused.
> Infra is telling "create ^/openoffice/updates-site/trunk/"
> Jan is proposing "^/openoffice/trunk/ooo-site/upates/"
> We already have "^/openoffice/ooo-site/trunk/content/projects/aoo40/"
>
> If we can use whatever location for URL https://updates.openoffice.org/, why
> does we had a discussion on a new location?
>
I think the concern is this:
1) We want SSL for 4.0. http://update.openoffice.org is not HTTPS.
2) The URL https://ooo-site.openoffice.apache.org supports SSL, but is
not considered "long term stable". The URL is an artifact of the CMS
3) We're looking for a stable URL. One could be
https://updates.openoffice.org, but that requires an SSL cert for
*.openoffice.org. But will that be supported in time for the AOO 4.0
release?
4) Backup plan is updates.openoffice.apache.org, which could be
supported via SSL today, using the *.apache.org cert. If we do that
we'd want to map that to its own CMS dir in SVN. so it can be updated
and published via the CMS.
-Rob
>
>>
>> Changing updates.o.o to point at something else is a one line statement so
>> no problem.
>>
>> Would it not be better if the AOO executable always called
>> https://updates.openoffice.org?version=x
>>
>> That way the executable stays stable over versions, and we can have 1
>> server side script that checks the version.
>>
>
> May be it would be better.
> But, somebody would be needed to implement such an adaption in the
> OpenOffice code and to implement the server side script.
>
> Best regards, Oliver.
>
>
>> rgds
>> jan I
>>
>> and have
>>
>>
>>>
>>>
>>>
>>> 2) let https://updates.openoffice.org point to trunk/ooo-site/update
>>>>
>>>>
>>>
>>> Yes, https://updates.openoffice.org should point to the new application
>>> update data location.
>>>
>>>
>>> Best regards, Oliver.
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 03.06.2013 13:50, janI wrote:
> On 3 June 2013 11:43, Oliver-Rainer Wittmann <or...@googlemail.com>wrote:
>
>> Hi,
>>
>> On 02.06.2013 16:43, janI wrote:
>>
>>> Hi.
>>>
>>> I have asked by my infra collegaues, to ensuere we (AOO) have consensus on
>>> how to handle updates.openoffice.org
>>>
>>> I nobody objects I will assume lazy consensus in 72 hours from now and
>>>
>>> 1) create trunk/ooo-site/upates
>>>
>>
>> My understandings of the communication with infra is that
>> ^/openoffice/updates-site/**trunk/
>> should be created for holding the needed application update data for AOO
>> 4.0 and later.
>>
>> I am not sure, if my understanding is correct.
>> Thus, please let us clarify it.
>>
>>
>> Just for your information - the locations for the released versions are:
>> - ^/openoffice/ooo-site/trunk/**content/projects/update/**aoo341/ used by
>> UpdateURL http://www.openoffice.org/**projects/update/aoo341/check.**
>> Update <http://www.openoffice.org/projects/update/aoo341/check.Update>for AOO 3.4.1
>> - ^/openoffice/ooo-site/trunk/**content/projects/update38/ used by
>> UpdateURL http://update38.services.**openoffice.org/**
>> ProductUpdateService/check.**Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>for AOO 3.4
>> - ^/openoffice/ooo-site/trunk/**content/projects/update36/ used by
>> UpdateURL http://update36.services.**openoffice.org/**
>> ProductUpdateService/check.**Update<http://update36.services.openoffice.org/ProductUpdateService/check.Update>for OOo 3.3
>> - ^/openoffice/ooo-site/trunk/**content/projects/update35/ used by
>> UpdateURL http://update35.services.**openoffice.org/**
>> ProductUpdateService/check.**Update<http://update35.services.openoffice.org/ProductUpdateService/check.Update>for OOo 3.2.1
>> - ^/openoffice/ooo-site/trunk/**content/projects/update34/ used by
>> UpdateURL http://update34.services.**openoffice.org/**
>> ProductUpdateService/check.**Update<http://update34.services.openoffice.org/ProductUpdateService/check.Update>for OOo 3.2
>>
>
> Using that we should make
> ^/openoffice/ooo-site/trunk/content/projects/update40/
> and have updates.o.o point at that.
We have already ^/openoffice/ooo-site/trunk/content/projects/aoo40/ for
current AOO 4.0 trunk builds - as stated in the communication with infra.
I am currently very confused.
Infra is telling "create ^/openoffice/updates-site/trunk/"
Jan is proposing "^/openoffice/trunk/ooo-site/upates/"
We already have "^/openoffice/ooo-site/trunk/content/projects/aoo40/"
If we can use whatever location for URL https://updates.openoffice.org/,
why does we had a discussion on a new location?
>
> Changing updates.o.o to point at something else is a one line statement so
> no problem.
>
> Would it not be better if the AOO executable always called
> https://updates.openoffice.org?version=x
>
> That way the executable stays stable over versions, and we can have 1
> server side script that checks the version.
>
May be it would be better.
But, somebody would be needed to implement such an adaption in the
OpenOffice code and to implement the server side script.
Best regards, Oliver.
> rgds
> jan I
>
> and have
>
>
>>
>>
>>
>> 2) let https://updates.openoffice.org point to trunk/ooo-site/update
>>>
>>
>> Yes, https://updates.openoffice.org should point to the new application
>> update data location.
>>
>>
>> Best regards, Oliver.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: updates.openoffice.org
Posted by janI <ja...@apache.org>.
On 3 June 2013 11:43, Oliver-Rainer Wittmann <or...@googlemail.com>wrote:
> Hi,
>
> On 02.06.2013 16:43, janI wrote:
>
>> Hi.
>>
>> I have asked by my infra collegaues, to ensuere we (AOO) have consensus on
>> how to handle updates.openoffice.org
>>
>> I nobody objects I will assume lazy consensus in 72 hours from now and
>>
>> 1) create trunk/ooo-site/upates
>>
>
> My understandings of the communication with infra is that
> ^/openoffice/updates-site/**trunk/
> should be created for holding the needed application update data for AOO
> 4.0 and later.
>
> I am not sure, if my understanding is correct.
> Thus, please let us clarify it.
>
>
> Just for your information - the locations for the released versions are:
> - ^/openoffice/ooo-site/trunk/**content/projects/update/**aoo341/ used by
> UpdateURL http://www.openoffice.org/**projects/update/aoo341/check.**
> Update <http://www.openoffice.org/projects/update/aoo341/check.Update>for AOO 3.4.1
> - ^/openoffice/ooo-site/trunk/**content/projects/update38/ used by
> UpdateURL http://update38.services.**openoffice.org/**
> ProductUpdateService/check.**Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>for AOO 3.4
> - ^/openoffice/ooo-site/trunk/**content/projects/update36/ used by
> UpdateURL http://update36.services.**openoffice.org/**
> ProductUpdateService/check.**Update<http://update36.services.openoffice.org/ProductUpdateService/check.Update>for OOo 3.3
> - ^/openoffice/ooo-site/trunk/**content/projects/update35/ used by
> UpdateURL http://update35.services.**openoffice.org/**
> ProductUpdateService/check.**Update<http://update35.services.openoffice.org/ProductUpdateService/check.Update>for OOo 3.2.1
> - ^/openoffice/ooo-site/trunk/**content/projects/update34/ used by
> UpdateURL http://update34.services.**openoffice.org/**
> ProductUpdateService/check.**Update<http://update34.services.openoffice.org/ProductUpdateService/check.Update>for OOo 3.2
>
Using that we should make
^/openoffice/ooo-site/trunk/content/projects/update40/
and have updates.o.o point at that.
Changing updates.o.o to point at something else is a one line statement so
no problem.
Would it not be better if the AOO executable always called
https://updates.openoffice.org?version=x
That way the executable stays stable over versions, and we can have 1
server side script that checks the version.
rgds
jan I
and have
>
>
>
> 2) let https://updates.openoffice.org point to trunk/ooo-site/update
>>
>
> Yes, https://updates.openoffice.org should point to the new application
> update data location.
>
>
> Best regards, Oliver.
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: updates.openoffice.org
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 02.06.2013 16:43, janI wrote:
> Hi.
>
> I have asked by my infra collegaues, to ensuere we (AOO) have consensus on
> how to handle updates.openoffice.org
>
> I nobody objects I will assume lazy consensus in 72 hours from now and
>
> 1) create trunk/ooo-site/upates
My understandings of the communication with infra is that
^/openoffice/updates-site/trunk/
should be created for holding the needed application update data for AOO
4.0 and later.
I am not sure, if my understanding is correct.
Thus, please let us clarify it.
Just for your information - the locations for the released versions are:
- ^/openoffice/ooo-site/trunk/content/projects/update/aoo341/ used by
UpdateURL http://www.openoffice.org/projects/update/aoo341/check.Update
for AOO 3.4.1
- ^/openoffice/ooo-site/trunk/content/projects/update38/ used by
UpdateURL
http://update38.services.openoffice.org/ProductUpdateService/check.Update for
AOO 3.4
- ^/openoffice/ooo-site/trunk/content/projects/update36/ used by
UpdateURL
http://update36.services.openoffice.org/ProductUpdateService/check.Update for
OOo 3.3
- ^/openoffice/ooo-site/trunk/content/projects/update35/ used by
UpdateURL
http://update35.services.openoffice.org/ProductUpdateService/check.Update for
OOo 3.2.1
- ^/openoffice/ooo-site/trunk/content/projects/update34/ used by
UpdateURL
http://update34.services.openoffice.org/ProductUpdateService/check.Update for
OOo 3.2
> 2) let https://updates.openoffice.org point to trunk/ooo-site/update
Yes, https://updates.openoffice.org should point to the new application
update data location.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org