Hi,
On 17.05.2012 03:13, Kay Schenk wrote:
On Wed, May 16, 2012 at 1:44 PM, Oliver-Rainer Wittmann<
[email protected]> wrote:
Hi,
On 16.05.2012 21:58, Kay Schenk wrote:
[snip]
One of the problems we will run into, esp for Linux (I don't know about
other platforms) is that the user has a appended "pkgfmt" already on the
update URL, so in my experimenting, the update call failed because an
acceptable package was not found.
From my point of view this should not be a problem as it seems that the
HTTP server neglects the URL query part in such a "static" case.
I am not an expert here, please correct me if I am wrong.
well, I'll try it again...I have several versions to play with...I seem to
recall I had to manually delete the pkgfmt business and then I got it to
work.
I have recently tested on Ubuntu with an old developer snapshot of AOO 3.4.
It just worked fine, even with an update URL having the query part.
OK...I recall I had to take this off and then it did work with getting me a
URL page.
I am not sure, if we both about the same.
Thus, please let me in more detail describe what I am observing:
For the "static" solution we would have a corresponding HTTP resource (our XML
document) at URL X. I see that the HTTP GET requests made by the update
functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb are answered by the
HTTP server. The response from the HTTP server contains the requested HTTP
resource - in our case the XML document.
Then the XML document is parsed by the update functionality in AOO 3.4 resp. OOo
3.3. Two cases needs to be distinguish here:
(1) XML document is in the simple form - only containing XML element
<inst:description> with corresponding childs.
(2) XML document is in the atom feed form
In case (1) the update functionality checks the following three conditions:
(a) <inst:os> content matches the one of the installed version
(b) <inst:arch> content mathes the one of installed version
(c) <inst:buildid> contant - BuildID of newer version - is greater than the
BuildID of the installed version.
Possible values for <inst:os> and <inst:arch> can be found in [1].
If the conditions hold further information are read - <inst:version> and
<inst:update> - and the user is presented the information that an update is
available together with the update URL.
If the conditions do not hold - e.g. empty <inst:description> element the user
is presented the information that installed version is up to date.
In case (2) the update functionality searches for entries which matches the
condition that attribute term of element <category> matches the one of installed
version. Then action as in case (1) are performed on each entry until an entry
matches the above conditions.
If, I understand your observations correct, you need to remove the query part
from the update URL in order to assure that the update functionality recieves
the XML document. Is this correct?
[1]
https://svn.apache.org/repos/asf/incubator/ooo/trunk/main/sal/rtl/source/macro.hxx
When I browse to http://update36.services.**openoffice.org/**
ProductUpdateService/check.**Update?pkgformat=deb<http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgformat=deb>using
the FireFox it provides me the content of the XML document.
BTW, I have already updated the XML document as you suggested. As I forgot
to include an entry for Linux 32bit in my first try you may be hit my first
XML document.
I'll get back to you on this later today.
Ok, thanks.
OK, well since I am at 3.4., I can't help much with this without editing
the XML doc yo have out there I'm afraid, so I will take your word for what
you say works and just hope we can get on with things.
Yes. When you are testing with a released AOO 3.4 you at least need to increase
the value of <inst:buildid> in the XML document to get the information from the
update functionality that an update is available.
I think I will make a discussion thread to totally ditch the pkgfmt
business
from Linux update URLs. It would considerably simplify our lives.
Do you mean for future versions of AOO?
yes...this would be best I think. Installing on Linux automatically can be
tricky if you're not root anyway. No harm in just shuttling folks to a page
to choose something and then do the install in my mind.
I never tried the automatic installation on Linux. I will hae a look in my
Ubuntu VM which has OOo 3.3 installed.
This may be possible, because this information could also "coded" into the
"User-Agent" field of the HTTP GET request.
I don't get your meaning here. Sorry. ????
The HTTP GET request contains information about the installed version making the
request. The needed package format is currently "coded" as the URL query part.
But, it could be also "coded" in the HTTP "User-Agent" field.
OK, the next step, which we should deal with very cautiously given my past
experiment, is to get infra to redirect update36.services.openoffice.org to
the web server IP address.
From my point of view we only should redirect the update URL of OOo 3.3 -
namely update36..... If it works fine, we can think of redirecting further
update URLs from former versions.
My personal opionion is that such redirects are not needed - but this is only my
view.
It would be better if we could just try this with a very limited set of
updates for the time being...maybe just 32 bit Linux German, for example,
and take out the others for a bit and see what happens.
The other thing is since we're still in the midst of the traffic for the
new release, it would be better to wait at least another week. I know
you've been after this for a while, and I completely understand, but well,
results were REALLY disastrous with the update30 re-route -- I kid you not.
Within 2 hours it incapacitated the Apache web server with the bad "post"
calls -- I mean ALL of it -- all sites, and the redirect had to be backed
out. I know we use "get" now and not post, but who would know this?
Yes, we should wait for at least one week to establish the update service for
OOo 3.3. And then only for OOo 3.3
Maybe infra has like a different server we could use -- with a web server
running on it, but not the main server. I'll try to find out tomorrow on
#asinfra or you could get on there and find out.
That is great that you are getting in contact with ASF infra regarding this
issue. Thx.
Best regards, Oliver.
