Return-Path: X-Original-To: apmail-openoffice-dev-archive@www.apache.org Delivered-To: apmail-openoffice-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 43747108B7 for ; Wed, 5 Jun 2013 23:55:49 +0000 (UTC) Received: (qmail 93806 invoked by uid 500); 5 Jun 2013 23:55:48 -0000 Delivered-To: apmail-openoffice-dev-archive@openoffice.apache.org Received: (qmail 93744 invoked by uid 500); 5 Jun 2013 23:55:48 -0000 Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openoffice.apache.org Delivered-To: mailing list dev@openoffice.apache.org Received: (qmail 93736 invoked by uid 99); 5 Jun 2013 23:55:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jun 2013 23:55:48 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kay.schenk@gmail.com designates 209.85.160.43 as permitted sender) Received: from [209.85.160.43] (HELO mail-pb0-f43.google.com) (209.85.160.43) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jun 2013 23:55:44 +0000 Received: by mail-pb0-f43.google.com with SMTP id md12so1392356pbc.2 for ; Wed, 05 Jun 2013 16:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=G7hHN5bxiI6U0JQI5iY9tH1lNl73uPRM6Fc8FESWbQM=; b=FRf/US1TpWYRvdRowxWQUTYRNF44PTXXZYDY/uM/raqoPqXV0KJox0Vv0R/zUY+vdC B87GAoOQyDhe7MGI3n8PqOaBGifMNGcXXHgT1HdQsu/NiaIqsc7lWmxRoKS06tyn4/Nc tHoXCiAzNe8TgjoYO2Ul13bBrd9bp42vN2BCnefs+VEEEuMl5ZKwIUe5Q76sWo1kVdGO v55nA1CsqNLz4DS1N5ISk0/djgLYYZN21DyZGTJ1NeeEPfapg8Bmwk3m8+9nUX7q2Gii 3fFf41r+A8jB9DjJ5u2bz3terTJfYFtZs9BFN/vmUI9GpWbN3fvhRr9hs9dCqCA37uLu UvMQ== MIME-Version: 1.0 X-Received: by 10.68.13.168 with SMTP id i8mr35963808pbc.86.1370476524399; Wed, 05 Jun 2013 16:55:24 -0700 (PDT) Received: by 10.70.1.194 with HTTP; Wed, 5 Jun 2013 16:55:24 -0700 (PDT) In-Reply-To: References: <51AC655D.1020106@googlemail.com> <51AC87D6.5050201@googlemail.com> <51AE4FB1.2050809@apache.org> <51AEFF61.8060402@googlemail.com> Date: Wed, 5 Jun 2013 16:55:24 -0700 Message-ID: Subject: Re: updates.openoffice.org From: Kay Schenk To: dev@openoffice.apache.org Content-Type: multipart/alternative; boundary=bcaec520efcf68f41a04de70ee56 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec520efcf68f41a04de70ee56 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 10:03 AM, janI wrote: > On 5 June 2013 18:37, Kay Schenk wrote: > > > On Wed, Jun 5, 2013 at 8:50 AM, janI wrote: > > > > > On 5 June 2013 17:43, Rob Weir wrote: > > > > > > > On Wed, Jun 5, 2013 at 11:34 AM, janI wrote: > > > > > On 5 June 2013 16:48, Rob Weir wrote: > > > > > > > > > >> On Wed, Jun 5, 2013 at 10:32 AM, janI 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/ ) 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 wrote: > > > > >> >>> > > > > >> >>> On Tue, Jun 4, 2013 at 5:59 PM, janI > wrote: > > > > >> >>>> > > > > >> >>>>> On 4 June 2013 22:36, Andrea Pescetti > > > > 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 > > > > >> >>>>>> < > > > > >> >>>>>> > > > > >> >>>>> 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 --bcaec520efcf68f41a04de70ee56--