On 5 June 2013 18:37, Kay Schenk <kay.sch...@gmail.com> wrote: > On Wed, Jun 5, 2013 at 8:50 AM, janI <j...@apache.org> wrote: > > > On 5 June 2013 17:43, Rob Weir <robw...@apache.org> wrote: > > > > > 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. > > > > > > > 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 <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 > > > > > > > > > > > > -- > > ---------------------------------------------------------------------------------------- > MzK > > "You can't believe one thing and do another. > What you believe and what you do are the same thing." > -- Leonard Peltier >
