Thank you both for clarifying this issue. Mirko
On Tue, Jan 26, 2010 at 10:28 AM, Bryan J Smith <[email protected]> wrote: > On Tue, 2010-01-26 at 08:17 -0500, Mirko Vukovic wrote: > > Hello, > > My firefox browser crashes about 2-3 times/week. Does anyone else > > have a similar experience? I did not yet try it in safe mode. > > Many Firefox add-ons and site scripts can hang/crash the browser via > nominal usage. These are not issues with Firefox itself. > > I started using NoScript ( http://noscript.net/ ) years ago to "opt-in" > to enabling scripting and add-ons for sites. By default, unless > disabled, NoScript _blocks_ everything but standard HTML and related > presentation. > > Since doing so, I virtually never crash/hang. The Red Hat Network (RHN) > version can be trusted to be updated with security vunerabilities > patched per Red Hat policies. > > Red Hat Enterprise Linux Errata Support Policy: > http://www.redhat.com/security/updates/errata/ > > Backporting of Security Fixes: > http://www.redhat.com/security/updates/backporting/ > > > On a tangential issue, the version of firefox that comes through yum > > is usually much older than the latest firefox official release. > > Considering that new releases usually have security fixes, I am > > tempted to install the latest version by myself. Any major reason > > why not do it? > > Just because the Mozilla Foundation is shipping 3.5 (or even 3.6) does > not mean 3.0 is unmaintained. The Mozilla Foundation just recently > moved to 3.6 and has deprecated 3.0, although this does not mean Red Hat > will not continue to backport security fixes on 3.0 until it decides to > rebase Firefox to a newer version. > > Red Hat's errata policy avoids rebasing software to avoid regressions, > tests before release, etc... while backporting fixes. E.g., > Mozilla-Gecko profiles may change every major revision, causing issues > with existing mandatory and default policies and related regressions. > I.e., If you maintain thousands of enterprise desktops, rebasing can be > a major issue. ;) > > There can also be unforseen issues and other problems with a major > Firefox revision. E.g., it was not by chance that Red Hat skipped > Firefox 2.0, waiting on Firefox 3.0 before rebasing from Firefox 1.5 > (circa EL4.7/5.2). If you believe this can be done lightly and easily, > then you've never managed 1,000+ enterprise _desktops_ before. ;) > > If you _really_ believe you _need_ to run another version, then I offer > the following for the latest Firefox i386. *YOU* now become responsible > for updating it though, not Red Hat. May the force be with you. ;) > > === PROCEDURE (install latest Firefox i386 into /usr/local/lib) === > > NOTE: "#" indicates a superuser prompt so type the exact command (sans > variables like "(ver")" as root. "[*#*]" indicates a note which > follows. > > Get Firefox: > - Download i386 tarball from Firefox from getfirefox.org > > Install Tarball: > # cd /usr/local/lib > # tar xzvf firefox-(ver).tar.gz > - Or, for bzip2: > # tar xjvf firefox-(ver).tar.bz2 > # mv firefox firefox-(ver) > - Since you're likely to download future versions too > > Binary Symlink: > # cd /usr/local/bin > # ln -s ../lib/firefox-(ver)/firefox firefox32 > - Or whatever you want to name it (ff32, etc...) > - Edit /usr/local/lib/firefox-(ver)/firefox > - Change "$0" to "firefox" (since binary name doesn't match symlink) > - Create GUI menu/bar launcher to "firefox32" > > Plugin Setup: [*1*] > # cd /usr/lib/mozilla > - Should have any installed 32-bit plug-ins > # find plugins -mount | cpio -pmdv /usr/local/lib/firefox-(ver) > - Possibly also: > # find plugins-wrapped | cpio -pmdv /usr/local/lib/firefox-(ver) > - Manually copy/symlink other plugins as well > - to: /usr/local/lib/firefox-(ver)/plugins > > SELinux Contexts: [*2*] > # chcon -R --reference=/usr/lib[64]/firefox-(ver) > /usr/local/lib/firefox-(ver) > - This leverages the distros included Firefox's contexts (F7+/RHEL5.2+) > # chcon -t textrel_shlib_t /usr/local/lib/firefox-(ver)/plugins/(plugin).so > > NOTES: > > [*1*] 32-bit Plug-ins > > If you are running EL/x86-64, do _not_ copy any plug-ins > from /usr/lib64/mozilla as they will be for the 64-bit version. Most > (all?) properly packaged programs with Gecko engines _should_ drop any > and all 32-bit plug-ins under /usr/lib/mozilla/plugins, so use the above > find|cpio command. > > On some systems, there may also be a /usr/lib/mozilla/plugins-wrapped > directory as well. > > [*2*] SELinux Contexts > > The first chcon command takes advantage of the fact that most newer > Fedora and RHEL releases actually locate the Firefox tree > under /usr/lib[64]/firefox-(ver) as appropriate for 32-bit (/usr/lib) > and 64-bit (/usr/lib64), and the trees are not much different than the > tarball download from getfirefox.org. It probably won't work for a > distro that ships old Firefox 1.5 when you're installing Firefox 2 or 3, > but it should on any distro with Firefox 2+. > > The second chcon command, setting the textrel_shlib_t, may be required > on various plugins under the ./plugins directory, if copied) or the > de-referenced shared object (.so) in another directory. E.g., ICAClient > (Citrix ICA Client aka XenApp). > > > -- > Bryan J Smith Senior Consultant Red Hat, Inc > Professional Consulting http://www.redhat.com/consulting > mailto:[email protected] +1 (407) 489-7013 (Mobile) > mailto:[email protected] (Blackberry/Red Hat-External) > -------------------------------------------------------- > You already know Red Hat as the entity dedicated to 100% > no-IP-strings-attached, community software development. > But do you know where CIOs rate Red Hat versus other > software and services firms for their own, direct needs, > year after year? http://www.redhat.com/promo/vendor/ > > > > _______________________________________________ > rhelv5-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv5-list >
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
