incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Rist <andrew.r...@oracle.com>
Subject Re: Disposition of *.services.oo.o
Date Thu, 27 Oct 2011 23:18:03 GMT
Looking into this further - I believe that 
download.services.openoffice.org will not be affected.
It should stay up along with all of the Kenai based services and svn.oo.o/hg
Andrew

On 10/27/2011 4:09 PM, Marcus (OOo) wrote:
> Am 10/22/2011 12:08 PM, schrieb Marcus (OOo):
>> Am 10/22/2011 01:56 AM, schrieb Marcus (OOo):
>>> Am 10/22/2011 01:37 AM, schrieb Dave Fisher:
>>>>
>>>> On Oct 21, 2011, at 4:16 PM, Marcus (OOo) wrote:
>>>>
>>>>> Am 10/21/2011 08:35 PM, schrieb Dave Fisher:
>>>>>> (2) downloads.services.oo.o goes away this needs attention. This
is
>>>>>> the major unknown.
>>>>>>
>>>>>> We do have a version of this page in the website migration. It is
>>>>>> rather clean. I think the page handles a missing mirror brain, but
I
>>>>>> don't know if it handles it well. The version that was cleaned up
is
>>>>>> in the AOOo project svn in ooo/ooo-site/trunk/content/download/.
>>>>>
>>>>> Yes, the complete download method rely on a working
>>>>> "download.services.oo.o" domain as here our Mirrorbrain instance is
>>>>> running to do the loadbalancing for download requests.
>>>>>
>>>>> As it wasn't accepted to bring this into the podling as another
>>>>> software service, we have to find another solution.
>>>>>
>>>>> 1) As short term solution we could switch to a system that we were
>>>>> allowed to use as backup for any outages we had at Sun/Oracle times.
>>>>>
>>>>> This system is running on "www.mirrorbrain.org" and is hosted and
>>>>> serviced by Peter Poeml. As long as the "download.openoffice.org"
>>>>> host is still working there shouldn't be bigger problems if we could
>>>>> use the backup system.
>>>>>
>>>>> I'll ask him if it's OK to rely this time a bit longer as long as we
>>>>> have not a long term solution (see other mail).
>>>>>
>>>>> 2) It seems to be time to connect to the ASF system to do software
>>>>> downloads. However, AFAIK we have the problem that the ASF is very
>>>>> likely not willing to host pre-ASF releases of OOo within their
>>>>> mirror network.
>>>>>
>>>>> Nevertheless we need to prepare our download webpages for the ASF
>>>>> method when we will have ready our first AOO release.
>>>>
>>>> It may be that we can use the ASF method of picking mirrors to select
>>>> from the current list of OOo mirrors.
>>>
>>> I've not yet tested which ASF mirrors already provide also OOo install
>>> sets. Or how to change the script, so that it accepts also other 
>>> mirrors.
>>>
>>> And the "http://www.apache.org/dyn/closer.cgi" script has to be 
>>> tweaked,
>>> so that it provides the suitable mirror *and* link to the OOo install
>>> set. Only a link to the closest mirror is not enough for end-users.
>>>
>>> A lot to do. However, for me this seems to be the long term solution.
>>>
>>> BTW:
>>> Here's the list of all OOo mirrors:
>>> http://download.services.openoffice.org/mirrors/all.html
>>
>> There is another host inside the *.services.oo.o domain. It's working as
>> FTP master server for the complete mirror network. A few big mirrors
>> sync from this master server to keep up-to-date with the release builds.
>> All other mirrors are sync'ing from these few big ones.
>>
>> I don't know exactly but it could happen that the release builds get
>> deleted because the master server is no longer reachable.
>>
>> I'll send a message to the old distribution.mirrors@, so that all mirror
>> admins are warned that the master server will be shutdown and they
>> should make sure that the OOo directory tree doesn't get deleted when
>> the rsync job starts to fails next week.
>>
>> Hopefully this will still reach enough mirror admins to keep the mirror
>> network stable somehow to satisfy future download requests.
>>
>> Marcus
>
> So far one 1 mirror admin in Switzerland had some doubts to keep the 
> mirror alive but I hope to convinced him to do so. No feedback from 
> others.
>
> Lets cross our fingers that enough mirrors will stay in the game.
>
> Marcus

-- 

Andrew Rist | Interoperability Architect
OracleCorporate Architecture Group
Redwood Shores, CA | 650.506.9847


Mime
View raw message