SCIENTIFIC-LINUX-USERS Archives

March 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jon Peatfield <[log in to unmask]>
Reply To:
Jon Peatfield <[log in to unmask]>
Date:
Fri, 30 Mar 2012 17:08:03 +0100
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (136 lines)
On Thu, 29 Mar 2012, Jaroslaw Polok wrote:

> On 03/29/2012 03:51 PM, Jaroslaw Polok wrote:
>> Hello
>>
>>> I'm not looking for theoretical replies, but rather someone who is _actually_
>>> doing it and has it working.  There must be someone out there who's got this
>>> worked out on SL/CentOS/TUV.
>>
>> We do.

And we do, though I've not yet pushed ff10 to most of our machines yet 
since we are still testing things...

>> with Firefox 10/Thunderbird 10 is is enough to drop files in
>> preferences directories (without altering original ones): these
>> are processed in sort order on startup.
>>
>> /usr/lib64/firefox/defaults/preferences/somefile.js
>> (/usr/lib64/thunderbird/defaults/pref/somefile.js)
>>
>> (of course change lib64 to lib on 32bit platform)
>>
>> Now, unfortunately it does not work for browser startup page,
>> apparently because of:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=461880
...

For the default startup homepage we make a slightly convoluted set of 
changes which does the 'right thing' for us.  Some of this may be possible 
to avoid but I know that doing all of this with ff10 on sl5 and sl6 works 
for us.

...
moz_inst="/usr/lib/firefox" (or lib64 for 64-bit version)

drop a .cfg file into $mos_inst/ we usually call ours damtp.cfg, this can 
set various defaults (or lock things) but not the browser startup homepage 
etc...

create a file $mos_inst/browserconfig.properties with content like:

--cut-here--
browser.startup.homepage=http://whatever.com
--cut-here--

create a file in $mos_inst/defaults/preferences/all-damtp.js (or your 
favourite name starting with a low letter!) with contents like:

// Dont edit this - it is machine generated by...
// Set the config file to load
pref("general.config.obscure_value", 0); // for MCD .cfg files
pref("general.config.filename", "damtp.cfg"); // or whatever you used
// Section for ffox-10
// This used to be in firefox.js but no more, so set here! 2012-03-12 JSP
pref("browser.startup.homepage", "resource:/browserconfig.properties");
//
// These urls are indicate a browser-change/welcome (for a new profile)
pref("startup.homepage_override_url", "$UPDURL");
pref("startup.homepage_welcome_url", "$UPDURL");
// end of section for ffox-10

All this is much like we had to do for ff3.6.x but the extra bit which 
*seems* to be needed for ff10 is to *ADD* browserconfig.properties into 
the existing omni.ja file ie something like:

  cd $moz_inst
  omni='omni.ja'
  cp -p $omni $omni.SL_Orig
  zip -r $omni browserconfig.properties

In fact we found that we needed to add a few other things into omni.ja, 
since the versions we drop into $mos_inst/ are ignored, so in fact we do 
(this is in simple perl but hopefully easy enough to read):

...
     my $omni='omni.ja';
     my $brs='browserconfig.properties';

     my $files="$brs defaults/profile/mimeTypes.rdf defaults/profile/bookmarks.html";
     if (-f $omni) {
 	dprin(4, "$omni present checking for $brs");
 	my $out=qx(unzip -l $omni $brs 2>/dev/null);
 	if ($out =~ /$brs/) { # already present, so update
 	    dprin(4, "Freshening $files in $omni");
 	    system("zip -f $omni $files >/dev/null 2>&1");
 	} else { # no present so back up omni first...
 	    dprin(4, "Back up $omni and add $files");
 	    system("cp -p $omni $omni.SL_Orig");
 	    system("zip -r $omni $files >/dev/null 2>&1");
 	}
     } else {
 	dprin(0, "No $omni found - is this really firefox 10+ ?");
     }
...

Some bits like defaults/profile/bootmarks.html *are* read from the 
$most_inst/ tree when a new profile is created but but if there is an 
empty profile (which is how I do most of my testing) it uses the one from 
omni.ja so I'd prefer to have them set to have the same content or I get 
confused later...

Here is another fun piece which you may or may not care about which hacks 
the .cfg file to avoid a problem with ff10 printing stuff which runs into 
the unprintable parts of the page (headers/footers usually):

...
my $damtpout="damtp.cfg";
...
# and hack stuff on the end to cope with the print-margins...
if ($ffoxtype == 100) {
     open (IN, "lpstat -v|");
     open (OUT, ">>$damtpout");
     print OUT "// Hacks based on what we used to have in firefox 3.6.x\n";
     while (<IN>) {
 	if (/^device for (\w+):/) {
 	    my $pr=$1;
 	    print OUT <<EOF;
// unwritable margins for $pr
defaultPref("printer_${pr}.print_unwriteable_margin_bottom", 20);
defaultPref("printer_${pr}.print_unwriteable_margin_left", 25);
defaultPref("printer_${pr}.print_unwriteable_margin_right", 25);
defaultPref("printer_${pr}.print_unwriteable_margin_top", 25);
EOF
 	}
     }
}
...

I could send you the entire script we use but it is mostly a mess dealing 
with every varient of firefox from 1.5 through to 10.0 with the hacks we 
found we needed...

  -- Jon

ATOM RSS1 RSS2