Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAP-ksogxNhu2s1c64ifuu3aGn0Y4BfAjLk+16-A+UfsD=gFocQ@mail.gmail.com>
References: 
 <CAK2iWdQYmRR2=KEkc2zrchPpFDKF2QV8ZyKCY3qvAJP8pK+FQA@mail.gmail.com>
	<51AC655D.1020106@googlemail.com>
	<CAK2iWdRXqCQKXAxQDHd8Wm3C_3o6MCdWMpA5OQp7WJyXDhfc0g@mail.gmail.com>
	<51AC87D6.5050201@googlemail.com>
	<CAP-ksohjj83Yj7FChEFx3TodAw0ud7UsvuyYxYYA385RvPHEOg@mail.gmail.com>
	<51AE4FB1.2050809@apache.org>
	<CAK2iWdSAw5cQ_RPC_Gwkh0AVVf+KEV9sxuiMA2r_S2==Jjnfjg@mail.gmail.com>
	<CAP-ksoj2wY5Wq2c8UiE9cv2ZVcY+wqtK2t0N_beq=sa6ZgOnSA@mail.gmail.com>
	<CAK2iWdRDbi-oF-Fv_88ed=qHPAB64c3hzgjM+YD5KOQ6eMEhDA@mail.gmail.com>
	<51AEFF61.8060402@googlemail.com>
	<CAK2iWdTh8Rj5Po1hy3yWY8=MPVNmWuYW81KsgOebxVm2QppqNw@mail.gmail.com>
	<CAP-ksojUA1f7wAQngf=BkG_e2UmDc+i=MhCrnb1qBrFypMWC8Q@mail.gmail.com>
	<CAK2iWdSr8-SaQqN2nbip9-NyVYmVpjzTHhxdi0goQDc-W67rWA@mail.gmail.com>
	<CAP-ksogxNhu2s1c64ifuu3aGn0Y4BfAjLk+16-A+UfsD=gFocQ@mail.gmail.com>
Date: Wed, 5 Jun 2013 17:50:02 +0200
Message-ID: 
 <CAK2iWdTQ4YV9xp3q5g68_MHBdiOCiBCKyZPe=XNaWGJeMvwf7Q@mail.gmail.com>
Subject: Re: updates.openoffice.org
From: janI <jani@apache.org>
To: dev@openoffice.apache.org
Content-Type: multipart/alternative; boundary=089e0122eef09999f004de6a2697

--089e0122eef09999f004de6a2697
Content-Type: text/plain; charset=ISO-8859-1

On 5 June 2013 17:43, Rob Weir <robweir@apache.org> wrote:

> On Wed, Jun 5, 2013 at 11:34 AM, janI <jani@apache.org> wrote:
> > On 5 June 2013 16:48, Rob Weir <robweir@apache.org> wrote:
> >
> >> On Wed, Jun 5, 2013 at 10:32 AM, janI <jani@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 <robweir@apache.org> wrote:
> >> >>>
> >> >>>  On Tue, Jun 4, 2013 at 5:59 PM, janI <jani@apache.org> wrote:
> >> >>>>
> >> >>>>> On 4 June 2013 22:36, Andrea Pescetti <pescetti@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
>
>

--089e0122eef09999f004de6a2697--