On 6 June 2013 04:15, Dave Fisher <w...@apache.org> wrote: > > On Jun 5, 2013, at 12:37 PM, 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.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 <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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
