On Wed, Jun 5, 2013 at 11:34 AM, janI <j...@apache.org> wrote:
> On 5 June 2013 16:48, Rob Weir <robw...@apache.org> wrote:
>
>> On Wed, Jun 5, 2013 at 10:32 AM, janI <j...@apache.org> wrote:
>> > On 5 June 2013 11:05, Oliver-Rainer Wittmann <orwittm...@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 <robw...@apache.org> wrote:
>> >>>
>> >>>  On Tue, Jun 4, 2013 at 5:59 PM, janI <j...@apache.org> wrote:
>> >>>>
>> >>>>> On 4 June 2013 22:36, Andrea Pescetti <pesce...@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-unsubscr...@openoffice.apache.org>
>> >>>> >
>> >>>>
>> >>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>> ------------------------------**------------------------------**
>> >>>> ---------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> dev-unsubscr...@openoffice.apache.org>
>> >>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> ------------------------------**------------------------------**---------
>> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> dev-unsubscr...@openoffice.apache.org>
>> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to