On Fri, 4 Jul 2008, Jon Peatfield wrote:

> On Fri, 4 Jul 2008, Stephan Wiesand wrote:
>
>> Hi Troy,
>> 
>> On Fri, 4 Jul 2008, Troy Dawson wrote:
>>
>>>  Hi Andreas,
>>>  They look the same as SL 52 packages because they are the same.  Which
>>>  always makes me suspicious on a major upgrade like this.  We did need to
>>>  update the prelink for SL 50, but that is already in the security errata
>>>  from an earlier security errata.
>>>
>>>  I personally do not use autoconfig and do not know how much this is going
>>>  to impact people.  How prevalent is this?
>> 
>> well, we know that at least Jon's site relies on it as well. I guess it's 
>> quite common at least on larger sites.
>
> We do it mostly to set a few defaults (like home pages etc), but we could 
> proably live without it for a while if we understood what else has changed... 
> :-)

And we do it mostly to ban the cache from the users' home directories. To 
avoid 50MB/user being occupied by cached web pages in their home 
directories and on our backup tapes.

>>>  It looks like the bug isn't even being worked on yet, even though it is
>>>  over a month old.  Part of me wants to wait, but another part of me hates
>>>  holding up a critical security errata.  And this one I've already messed
>>>  up and let it slip a couple of days.
>>>
>>>  What if I sent out the security errata with a warning that says to put 
>>> the
>>>  link there if you need to run autoconfig?
>> 
>> It's not just the link, the config files also have to be installed in 
>> different locations.
>
> That can be worked round easily enough (I hope)...

Right. But it still has to be done, or autoconfig simply won't work.

>> And of course there are more serious changes that will cause headaches fro 
>> sites doing central administration and/or having home directories on 
>> central filesystems. /usr/lib/firefox-<version>/plugins is no longer 
>> searched (breaking the jpackage way of providing the java plugin).
>
> I see that there is a %{_libdir}/xulrunner-<version>/plugins/ directory so 
> perhaps that either is the new place or should be linked to from 
> firefox-<version>/ to be searched...  xulrunner-<version>/plugins seems to 
> end up with libnullplugin.so and libunixprintplugin.so in it.

If you find out, please let us know...

>> And the consequences of having an sqlite DB in ~/.mozilla - which is 
>> fsync'ed several times per web page loaded - could be quite serious for 
>> sites with ~  in NFS or (especially) AFS.
>
> There was an open bug about this which pointed out several options.  The 
> firefox rpm changelog is silent on whether any of the options were being 
> included.  I suppose I should look to see what if any patches are included...

Again, please let us know...

And even if the impact on fileservers could be reduced, we'd still face 
the fact that this 50MB+ sqlite file will end up - entirely - on tape, 
every single day, for every single active user, on any site doing daily 
backups of home directories. Just do the math: it's serious. On a site of 
our size, with a typical retention policy (180 days), *dozens* of tapes 
will be occupied by nothing but firefox bookmarks'n stuff. Actually, it's 
a crying shame.

Cheers,
 	Stephan

>> This update is quite a nightmare. Our site can not and will not roll it out 
>> for the time being, certainly not on a friday. Other sites may appreciate a 
>> big fat warning and/or some more delay. But then, those likely to have 
>> serious trouble should be controlling and testing their updates anyway.
>
> I won't have time to finish testing today but I have started...
>
> I note that with a new profile the default ffox-3 now starts up with two tabs 
> open to:
>
>  http://www.redhat.com/firefox-welcome/
>
>  file:///usr/share/doc/HTML/index.html
>
> I guess that the former may need changing not to point at RH...
>
> -- Jon
>

-- 
Stephan Wiesand
   DESY - DV -
   Platanenallee 6
   15738 Zeuthen, Germany