On Aug 14, 2012, at 12:42 PM, Dave Fisher wrote:
>
> On Aug 14, 2012, at 12:31 PM, Rob Weir wrote:
>
>> On Tue, Aug 14, 2012 at 3:25 PM, Dave Fisher <[email protected]> wrote:
>>>
>>> On Aug 14, 2012, at 12:09 PM, Oliver-Rainer Wittmann wrote:
>>>
>>>> Hi,
>>>>
>>>> Am 14.08.2012 um 20:52 schrieb Dave Fisher <[email protected]>:
>>>>
>>>>>
>>>>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>>>>>
>>>>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <[email protected]>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Aug 5, 2012, at 11:13 AM, Andrea Pescetti wrote:
>>>>>>>
>>>>>>>> On 03/08/2012 Rob Weir wrote:
>>>>>>>>> On Fri, Aug 3, 2012 at 6:13 AM, Oliver-Rainer Wittmann
>>>>>>>>> wrote:
>>>>>>>>>> I am planning to give a talk on ApacheCon EU about
>>>>>>>>>> the update function in AOO and the Update Service. In this talk I
>>>>>>>>>> will give
>>>>>>>>>> a deep insight in its purpose and functionality which should be
>>>>>>>>>> enough input
>>>>>>>>>> for a corresponding volunteer to create a "real" web service for our
>>>>>>>>>> Update
>>>>>>>>>> Service. ...
>>>>>>>>> The question is: how dynamic does it need to be? It is not like the
>>>>>>>>> upgrade options change minute by minute. These change slowly, at the
>>>>>>>>> pace of our release cycle, so every few months.
>>>>>>>>
>>>>>>>> Yes, and traffic is a key factor here. With potentially hundreds of
>>>>>>>> millions of clients hitting the servers, the biggest problem is not
>>>>>>>> re-implementing the update service as a web service, but serving it
>>>>>>>> efficiently. And indeed I agree that staticizing the results somehow
>>>>>>>> would be good to do, since we have a relatively low number of possible
>>>>>>>> answers with respect to the number of requests.
>>>>>>>
>>>>>>> Oliver requested removal of update32 from DNS on INFRA-5112 and now
>>>>>>> Infra is requesting PPMC agreement.
>>>>>>>
>>>>>>> Is now a time to discuss cleaning up all of the staroffice urls here:
>>>>>>>
>>>>>>> update.services CNAME sd-web4.staroffice.de.
>>>>>>> update23.services CNAME sd-web2.staroffice.de.
>>>>>>> update24.services CNAME sd-web2.staroffice.de.
>>>>>>> update30.services CNAME sd-web2.staroffice.de.
>>>>>>> update31.services CNAME sd-web2.staroffice.de.
>>>>>>> update32.services CNAME www.openoffice.org.
>>>>>>> update33.services CNAME sd-web2.staroffice.de.
>>>>>>> update34.services CNAME www.openoffice.org.
>>>>>>> update35.services CNAME www.openoffice.org.
>>>>>>> update36.services CNAME www.openoffice.org.
>>>>>>> update38.services CNAME www.openoffice.org.
>>>>>>>
>>>>>>> update32 is the proposed change in the JIRA issue.
>>>>>>>
>>>>>>> update33 is the added removal.
>>>>>>>
>>>>>>> What about update, update23, update24, update30, update31?
>>>>>>>
>>>>>>> Should we do anything now as well?
>>>>>>>
>>>>>>
>>>>>> I suppose returning errors from *.openoffice.org is no worse than
>>>>>> returning errors from *.staroffice.de. And if we do that we can
>>>>>> handle these URL's more gracefully in the future if we want to.
>>>>>
>>>>> It might be nicer to return a 404 rather than timing out on a
>>>>> non-responsive ip address.
>>>>>
>>>>> Oliver or Kay will need to confirm what will happen.
>>>>
>>>> I would like to see a 404 for all currently unused updateX*.services URLs.
>>>> The former OOo versions which would get in contact with these URLs should
>>>> handle such replies.
>>>
>>> The following are current in ooo-site/trunk/content/projects/.
>>>
>>> update:
>>> ProductUpdateService aoo341
>>>
>>> update30:
>>> ProductUpdateService
>>>
>>> update34:
>>> ProductUpdateService
>>>
>>> update35:
>>> ProductUpdateService
>>>
>>> update36:
>>> ProductUpdateService
>>>
>>> update38:
>>> ProductUpdateService
>>>
>>> (1) Are update/ProductUpdateSerice and update30/ProductUpdateService ready?
The DNS is now done. ooo-site may be changed as needed.
>>>
>>
>> They can be created quickly, based on available time of volunteers.
>> But if we have Infra now ready to act on the redirection now, let's
>> take advantage of that now, while we have that opportunity.
>>
>>> (2) Currently all 404s on openoffice.org go here:
>>>
>>> ErrorDocument 404 /docs/custom_404.html
>>>
>>> Is that acceptable? Or must we use a real 404 response?
>>>
>>
>> Please redirect them to where they would actually live if we wanted to
>> go live with then. e.g., the appropriate directory under
>> ooo-site/content/projects/updateXX
>>
>> In other words, treat them analogously to how we treat the others.
>> That way they will indeed give 404's now and then we can update then
>> for real without requiring intervention from Infra.
>
> These urls get rewritten by this default rule:
>
> # fallback for proj.openoffice.org/... to openoffice.org/projects/proj/...
> RewriteCond ${lowercase:%{HTTP_HOST}}
> ^(?!www)(\w+)(?:\.\w+)?\.openoffice\.org$
> RewriteRule ^(.*)$ ${lowercase:%{HTTP_HOST}}$1 [C]
> RewriteRule ^(\w+)(?:\.\w+)?\.openoffice\.org/(.*)
> http://www.openoffice.org/projects/$1/$2 [NE,L]
>
> We should probably add:
>
> <Directory /projects>
> ErrorDocument 404 default
> </Directory>
>
> Correct me if I'm wrong but that should make anything in that tree return a
> real 404.
Done and tested. [1] is updated.
Regards,
Dave
https://cwiki.apache.org/confluence/display/OOOUSERS/Open+Infrastructure+Requests
>
> And overrides:
>
> ErrorDocument 404 /docs/custom_404.html
>
>
> Regards,
> Dave
>
>
>
>>
>> Thanks,
>>
>> -Rob
>>
>>> Regards,
>>> Dave
>>>
>>>>
>>>> Best regards, Oliver.
>>>>
>>>>
>>>
>
