{"id":431,"date":"2011-08-27T19:11:29","date_gmt":"2011-08-28T02:11:29","guid":{"rendered":"http:\/\/blog.networkpresence.co\/?p=431"},"modified":"2011-08-28T03:59:52","modified_gmt":"2011-08-28T10:59:52","slug":"installing-64bit-flash-player-for-firefox-on-centos-5-6","status":"publish","type":"post","link":"http:\/\/blog.networkpresence.co\/?p=431","title":{"rendered":"Installing 64bit Flash player for Firefox on CentOS 5.6"},"content":{"rendered":"

After a recent ‘yum upgrade’ on a 64bit (x86_64) CentOS 5.6 based desktop system, I found that Flash sites weren’t working and that there were many “npviewer.bin” processes left in a Zombie process state and that web browsing was just generally slow.<\/p>\n

The solution to this was to ensure that the only Flash plugin & software on the system was from a single 64bit Flash plugin distribution from Adobe, as the dependencies of Firefox installed via Yum meant that a 32bit instance of Flash player was being installed from the RPM Forge Repo.<\/p>\n

The steps taken to fix Flash based browsing were:<\/p>\n

a) As root run ‘yum remove flash-plugin.i386<\/code>‘<\/p>\n

b) Then find any files in the root (\/) or \/usr directory trees named based on the glob “*flash*plugin*” and remove<\/strong> those files too.
\nThese files were found to be:
\n\/usr\/lib\/mozilla\/plugins-wrapped\/nswrapper_32_32.libflashplayer.so
\n\/usr\/lib64\/mozilla\/plugins-wrapped\/nswrapper_32_64.libflashplayer.so
\n\/usr\/lib64\/mozilla\/plugins\/libflashplayer.so<\/code><\/p>\n

The file ‘\/usr\/lib64\/mozilla\/plugins\/libflashplayer.so’ was a symlink to \/usr\/lib64\/flash-plugin\/libflashplayer.so, which didn’t exist (!), so that directory (\/usr\/lib64\/flash-plugin\/) was created (as root run mkdir \/usr\/lib64\/flash-plugin<\/code>).<\/p>\n

c) If the Firefox browser thinks that it does have a Flash plugin installed, then disable that plugin in Firefox and exit Firefox.<\/p>\n

d) Then the latest 64-bit Flash Plugin was downloaded from Adobe, at the URL: http:\/\/labs.adobe.com\/downloads\/flashplayer11.html<\/code> being http:\/\/download.macromedia.com\/pub\/labs\/flashplatformruntimes\/flashplayer11\/flashplayer11_b2_install_lin_64_080811.tar.gz<\/code>
\nThis file needs to be extracted in the \/ directory tree, as the files in that tar archive are:<\/p>\n

libflashplayer.so
\nusr\/bin\/flash-player-properties
\nusr\/share\/pixmaps\/flash-player-properties.png
\nusr\/share\/kde4\/services\/kcm_adobe_flash_player.desktop
\nusr\/share\/applications\/flash-player-properties.desktop
\nusr\/share\/icons\/hicolor\/32x32\/apps\/flash-player-properties.png
\nusr\/share\/icons\/hicolor\/22x22\/apps\/flash-player-properties.png
\nusr\/share\/icons\/hicolor\/24x24\/apps\/flash-player-properties.png
\nusr\/share\/icons\/hicolor\/16x16\/apps\/flash-player-properties.png
\nusr\/share\/icons\/hicolor\/48x48\/apps\/flash-player-properties.png
\nusr\/lib\/kde4\/kcm_adobe_flash_player.so<\/code><\/p>\n

e) After extracting the tar.gz in the \/ directory, the file \/libflashplayer.so needs to be moved to the valid location for the Firefox browser, which is that path found with the ‘find’ command above in (a), being: \/usr\/lib64\/flash-plugin\/libflashplayer.so
\nie:<\/code>
\nmv \/libflashplayer.so \/usr\/lib64\/flash-plugin\/libflashplayer.so<\/code>
\nThen ensure that the symlink found in (a) is now validly pointing to the now existing file \/usr\/lib64\/flash-plugin\/libflashplayer.so<\/em>
\nie:
\nls -lL \/usr\/lib64\/mozilla\/plugins\/libflashplayer.so<\/code><\/p>\n

f) Now knowing that the downloaded Flash 64-bit Plugin is the only one available to Firefox, you can launch Firefox & test the Flash player.<\/p>\n

This process worked successfully for me to restore Flash playing in Firefox on a 64-bit CentOS 5.6 desktop, whereas any attempts to use a Flash player via Yum from either the RPM Forge or Adobe’s own Repositories would never work.<\/p>\n","protected":false},"excerpt":{"rendered":"

After a recent ‘yum upgrade’ on a 64bit (x86_64) CentOS 5.6 based desktop system, I found that Flash sites weren’t working and that there were many “npviewer.bin” processes left in a Zombie process state and that web browsing was just … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54],"tags":[81,80,79],"class_list":["post-431","post","type-post","status-publish","format-standard","hentry","category-rich","tag-64-bit-centos","tag-firefox","tag-flash"],"_links":{"self":[{"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/posts\/431","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=431"}],"version-history":[{"count":4,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/posts\/431\/revisions"}],"predecessor-version":[{"id":435,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/posts\/431\/revisions\/435"}],"wp:attachment":[{"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=431"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=431"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=431"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}