June 3, 2007
I’ve tried to get Flash working with Firefox on FreeBSD a number of times, but haven’t been able to get it just right until recently.
I’m using,
FreeBSD 6.1-RELEASE #0: Sun May 7 04:32:43 UTC 2006
with
firefox-2.0_2,1.
The following worked for me (Thanks to a post from Lluis López: here).
1. First install linuxpluginwrapper from the ports tree:
cd usr/ports/www/linuxpluginwrapper
make
make install
make clean
2. Now go to /usr/src and get this patch and patch
cd /usr/src
patch < /home/work/rtld_dlsym_hack.diff
cd libexec/rtld-elf
make clean
make
make install
Substitute the correct path above !! (I downloaded the patch to /home/work/).
This assumes you have sources installed. If the tree under /usr/src is empty, then
sysinstall
[configure >> distributions >> src >> all ]
See The FreeBSD handbook if you’ve forgotten how to use sysinstall.
3. Install linux-flashplugin7
cd /usr/ports/www/linux-flashplugin7
make
make install
make clean
4. Copy /usr/local/share/examples/linuxpluginwrapper/libmap.conf-FreeBSD6 to /etc/libmap.conf
cp /usr/local/share/examples/linuxpluginwrapper/libmap.conf-FreeBSD6 /etc/libmap.conf
No need to edit /etc/libmap.conf.
5. Add symlinks in /usr/local/lib/browser_plugins to libflashplayer.so and flashplayer.xpt to
cd /usr/local/lib/browser_plugins
ln -s /usr/X11R6/lib/linux-mozilla/plugins/libflashplayer.so .
ln -s /usr/X11R6/lib/linux-mozilla/plugins/flashplayer.xpt .
6. Restart your browser, and navigate to about:plugins, you should see shockwave_flash listed:
Shockwave Flash
- File name:
libflashplayer.so
-
Shockwave Flash 7.0 r69
| MIME Type |
Description |
Suffixes |
Enabled |
| application/x-shockwave-flash |
Shockwave Flash |
swf |
Yes |
| application/futuresplash |
FutureSplash Player |
spl |
Yes |
7. Install javavmwrapper
Before we can install Java (I’m using the diablo-jdk from the FreeBSD Foundation in this example) we need to install javavmwrapper from ports.
cd /usr/ports/java/javavmwrapper/
make
make install
make clean
8. Now we can install Java. Download the appropriate JDK package from The FreeBSD foundation and simply issue a pkg_add.
In my case,
pkg_add diablo-jdk-freebsd6.i386.1.5.0.07.01.tbz
8. We need to add a symlink in /usr/local/lib/browser to /usr/local/diablo-jdk1.5.0/jre/plugin/i386/ns7/libjavaplugin_oji.so
cd /usr/local/lib/browser_plugins
ln -s /usr/local/diablo-jdk1.5.0/jre/plugin/i386/ns7/libjavaplugin_oji.so .
9. Restart your browser and navigate to about:plugins you should see
Java(TM) Plug-in diablo-1.5.0-b01
- File name:
libjavaplugin_oji.so
-
Java(TM) Plug-in 1.5.0
| MIME Type |
Description |
Suffixes |
Enabled |
| application/x-java-vm |
Java |
|
Yes |
| application/x-java-applet |
Java |
|
Yes |
| application/x-java-applet;version=1.1 |
Java |
|
Yes |
| application/x-java-applet;version=1.1.1 |
Java |
|
Yes |
| application/x-java-applet;version=1.1.2 |
Java |
|
Yes |
| … snipped … |
| application/x-java-bean;jpi-version=1.5 |
Java |
|
Yes |
I tested the Java install by trying the Rubik’s Cube Java Applet. It worked without problems.
Verifiying the Java installation at Sun’s site gives a (soft) error:
Oops! You don’t have the recommended Java installed.
Your Java version is 1.5.0. Please click the button below to get the recommended Java for your computer.
It does however verify that Java version 1.5.0 is installed.
Addendum: An alternative way to install Flash for Firefox, that bypasses the Linux compatibility layer altogether is to use the GNU Flash movie playergnash.
cd /usr/ports/graphics/gnash/
make
make install
make clean
Thanks to Matteo at Matteo’s Wasps’ Nest for this one. See his post for more details.
May 4, 2006
I just installed Java on my FreeBSD box. In the past it has been a nightmare to install Java due to licensing issues – BUT – the FreeBSD Foundation has negotiated a license with Sun to distribute JRE and JDK binaries for FreeBSD.
Installation is now very easy! Download the appropriate package from here and simply issue a pkg_add.
In my case it was
pkg_add diablo-jdk-freebsd6.i386.1.5.0.07.01.tbz
(I am currently running FreeBSD 6.1).
My installation baulked because javavmwrapper was not installed. A simple install from ports was all that was needed (it is a small package).
cd /usr/ports/java/javavmwrapper/
make
make install
make clean
After this I ran pkg_add again and the install went through without incident. It sure beats compiling the whole thing from sources.
February 22, 2006
To get awstats to work with qmail log files I use this little script from Bob Hutchinson called qlogs4awstats.
Download the file and edit the lines below to reflect your local paths. Most likely only the third line below
will need to be edited, to reflect where you have installed awstats.
chdir(“/var/log/qmail/qmail-send”);
my $taiprog = “/usr/local/bin/tai64nlocal”;
my $mailconvprog = “/usr/local/www/awstats/tools/maillogconvert.pl standard”;
Once edited move it to /usr/local/bin and chmod it so that it is executable.
Next copy awstats.model.conf to awstats.mail.conf or whatever you want to call your conf file.
You will have to edit your awstats.mail.conf in the following places. Note that in the first line there is a space after the pipe character | .
LogFile="/usr/local/bin/qlogs4awstats 3600 | "
LogType=M
LogFormat="%time2 %email %email_r %host %host_r %method %url %code %bytesd"
HostAliases="localhost 127.0.0.1 @locals"
LevelForBrowsersDetection=0 # 0 disables Browsers detection.
LevelForOSDetection=0 # 0 disables OS detection.
LevelForRefererAnalyze=0 # 0 disables Origin detection.
LevelForRobotsDetection=0 # 0 disables Robots detection.
LevelForSearchEnginesDetection=0 # 0 disables Search engines detection.
LevelForKeywordsDetection=0 # 0 disables Keyphrases/Keywords detection.
LevelForFileTypesDetection=0 # 0 disables File types detection.
ShowSummary=HB
ShowMonthStats=HB
ShowDaysOfMonthStats=HB
ShowDaysOfWeekStats=HB
ShowHoursStats=HB
ShowDomainsStats=0
ShowHostsStats=HBL
ShowRobotsStats=0
ShowEMailSenders=HBML
ShowEMailReceivers=HBML
ShowSessionsStats=0
ShowPagesStats=0
ShowFileTypesStats=0
ShowOSStats=0
ShowBrowsersStats=0
ShowOriginStats=0
ShowKeyphrasesStats=0
ShowKeywordsStats=0
ShowMiscStats=0
ShowHTTPErrorsStats=0
ShowSMTPErrorsStats=1
You can download my sample awstats.mail.conf with the above changes from here .
January 13, 2006
When installing ports from the ports tree, I was intrigued by this message for a long time:
root@t2# make
===> Vulnerability check disabled, database not found
I never really had time to check out what the vulnerability check was and what the database it refered to was. Some time later, in an unrelated context I came across portaudit under /usr/ports/security/portaudit
The package description reads
portaudit provides a system to check if installed ports are listed in a
database of published security vulnerabilities.
After installation it will update this security database automatically and
include its reports in the output of the daily security run.
…
This sounded like a good idea, I especially liked the idea of getting the vulnerabilities reported along with the daily output run.
Once installed the message about the vulnerability check being disabled goes away, which makes sense.
Installation from ports
root@t2# cd /usr/ports/security/portaudit
root@t2# make install
===> Installing for portaudit-0.5.10
===> Generating temporary packing list
===> Checking if security/portaudit already installed
===> To check your installed ports for known vulnerabilities now, do:
/usr/local/sbin/portaudit -Fda
===> Compressing manual pages for portaudit-0.5.10
===> Registering installation for portaudit-0.5.10
Interestingly and usefully, if you try to make a port that is vulnerable, portaudit complains loudly and won’t let you build it. It suggests you cvsup the ports tree and get the latest patched version of what you are trying to install.
Here’s a sample of a mailout from one of the machine:
Checking for a current audit database:
Downloading fresh database.
32063 bytes transferred in 0.0 seconds (712.35 kBps)
New database installed.
Database created: Thu Nov 24 02:40:19 CST 2005
Checking for packages with security vulnerabilities:
Affected package: squid-2.5.11_2
Type of problem: squid — FTP server response handling denial of service.
Reference: <http ://www.FreeBSD.org/ports/portaudit/1c3142a3-4ab2-11da-932d-00055d790c25.html>
Affected package: lynx-2.8.5
Type of problem: lynx — remote buffer overflow.
Reference: <http ://www.FreeBSD.org/ports/portaudit/c01170bf-4990-11da-a1b8-000854d03344.html>
Affected package: ruby-1.8.2_4
Type of problem: ruby — vulnerability in the safe level settings.
Reference: <http ://www.FreeBSD.org/ports/portaudit/1daea60a-4719-11da-b5c6-0004614cc33d.html>
Affected package: openssl-0.9.8_1
Type of problem: openssl — potential SSL 2.0 rollback.
Reference: <http ://www.FreeBSD.org/ports/portaudit/60e26a40-3b25-11da-9484-00123ffe8333.html>
As you can see, portaudit advises of vulnerabilities in your installed software on a daily basis, allowing you to patch things in a timely manner.
January 12, 2006
Part of my daily security routine is to check machine logs for signs of suspicious activity. Recently I found a few shell commands showing up in the Apache error log of one of the machines. It took a long time to track down the problem. In the end I found it was due to a poorly written and insecure script. This script was on the server when I inherited it from the previous administrator (figuring out which script was causing the problems is a story in itself).
After securing the script I couldn’t help but worry that something might have been dropped onto the server. In fact, after looking around I found a few files in /tmp and a couple in some places where apache had write access. I decided to look around for a tool to help me figure out if anything important had been tampered with. A quick look through the ports turned up rkhunter under /usr/ports/security/rkhunter.
The package description reads:
Rootkit Hunter is scanning tool to ensure you for about 99.9% you’re clean of nasty tools.
This tool scans for rootkits, backdoors and local exploits by running tests like:
- MD5/SHA1 hash compare
- Look for default files used by rootkits
- Wrong file permissions for binaries
- Look for suspected strings in LKM and KLD modules
- Look for hidden files
- Optional scan within plaintext and binary files
WWW: http://www.rootkit.nl/
Installing from ports is easy:
cd /usr/ports/security/rkhunter
followed by
make install && make clean
and rkhunter is installed (you may also wish to install portaudit1).
The post-install blurb suggests a typing rkhunter as a first step. This gives rkhunter’s command line options.
The –update option updates rkhunter’s databases and is a good first step.
rkhunter --update
root@t2# rkhunter –update
Running updater…
Mirrorfile /usr/local/lib/rkhunter/db/mirrors.dat rotated
Using mirror http://www.rootkit.nl/rkhunter
[DB] Mirror file : Up to date
[DB] MD5 hashes system binaries : Update available
Action: Database updated (current version: 2005051900, new version 2005121400)
[DB] Operating System information : Update available
Action: Database updated (current version: 2005052200, new version 2005102800)
[DB] MD5 blacklisted tools/binaries : Up to date
[DB] Known good program versions : Update available
Action: Database updated (current version: 2005041700, new version 2005111500)
[DB] Known bad program versions : Update available
Action: Database updated (current version: 2005041700, new version 2005111500)
Ready.
Now that the database is up to date it is time to run rkhunter in check mode (–checkall or -c)
rkhunter -c
Here is a sample of the output:
root@t2# rkhunter -c
Rootkit Hunter 1.2.7 is running
Determining OS... Ready
Checking binaries
* Selftests
Strings (command) [ OK ]
* System tools
Performing 'known good' check...
/bin/cat [ OK ]
/bin/chmod [ OK ]
/bin/kill [ OK ]
/bin/ls [ OK ]
...
Check rootkits
* Default files and directories
Rootkit '55808 Trojan - Variant A'... [ OK ]
ADM Worm... [ OK ]
Rootkit 'AjaKit'... [ OK ]
Rootkit 'aPa Kit'... [ OK ]
Rootkit 'Apache Worm'... [ OK ]
...
* Suspicious files and malware
Scanning for known rootkit strings [ OK ]
Scanning for known rootkit files [ OK ]
...
It does seem to do a fairly thorough job in checking for a lot of things. It can be run as a cron job (the –cronjob switch takes out the colorized output).
Note: RK Hunter copies /etc/group and /etc/passwd to root’s home directory. So don’t have a coronary if you spot them in there (I nearly did).

[1] Portaudit is used by rkhunter to check for vulnerable applications, it is useful but not actually necessary to have it installed. It can be found under /usr/ports/security/portaudit.