On Fri, 4 Jul 2008, Stephan Wiesand wrote:

> On Fri, 4 Jul 2008, Jon Peatfield wrote:
>
<snip>
>>  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.

Hmm, hadn't thought of that.  We used to force the cache size down low but 
not the location.  Maybe moving it into a suitable tmp (or tmp-like) 
place would actually work.  That sounds like a very good idea, I must 
steal it at once!!

I suppose you need a different Cache directory for each active profile or 
the browsers will corrupt things.  How do you arrange that?

...
>> >  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.

Yup - agreed.  Perhaps we can add a 'compatability symlink'... :-)

>>  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...

Doing:

   ln -s /usr/lib/xulrunner-1.9/plugins  /usr/lib/firefox-3.0/

causes 'Default Plugin' etc to appear in about:plugins, and then adding 
links for java and flashplayer into that directory causes them to show up 
too.

The flashplayer runs well enough to show the version when it is pointed at 
http://www.adobe.com/products/flash/about/ and the java works at least 
well enough for http://www.java.com/en/download/help/testvm.xml to show 
the little dancing image.

>> >  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.

Yup I strongly agree.

We currently back up most home directories roughly every 8 hours 
(secretaries' home directories a bit more frequently) using rsync and 
hard-link-trees so this would cause the files to need to be re-copied 
rather often.  We push stuff to tape less frequently but with ~1200 users 
50MB+ of sqlite adds up to ~180GB per day of extra pointless copying for 
us and would probably cause us to need a rather bigger backup-file-server 
fairly quckly.

We will either have to exclude the sqlite bits or something similar to 
avoid wasting too much space.  Maybe we should have the entire set of ffox 
profiles kept in a seperate directory tree that we don't back up (or at 
least not as often).

My test ffox-3 profile isn't very big yet though I expect it will get big 
later!

Hmm, this will probably also affect the windows firefox-3 versions for 
people where we map their home directory/profile into a samba share.

> Cheers,
> 	 Stephan

anyway enough testing for today, I'm off to the pub...

  -- Jon