This page is here as a catch-all for bits of information, tips and tricks for FreeBSD that I've picked up along the way that aren't large enough to warrant individual pages. Some of the tips are cosmetic, some are usability improvements and some are just there cause I found the information handy to know. They are presented in no particular order (for now).
There's this nifty little feature of the new(er) pkg tool for auditing your installed packages (and ports, since they get rolled into pkgdb).
pkg audit -F
will get you a freshly-fetched database of vulnerable packages, then check your system. Fix anything that's broken if you can; consider uninstalling or making unavailable things that you can't fix until you can fix them.
The nightly security script /usr/local/etc/periodic/security/410.pkg-audit will report vulnerable packages by default in your nightly security e-mails. You do read your nightly security e-mails, don't you?
pkg audit, combined with a nice subscription to freebsd-security-notifications@freebsd.org, can go a long way towards keeping you informed of potential security problems with your machine.
Updating ports is a pretty trivial thing; take a look at the next section.
ports-mgmt/portupgrade is a handy little utility that's nice for upgrading installed software on your machine. You can alter make information for a port that portupgrade is working on (-m and -M flags), supply a command, do things before and after portupgrade does certain things (-A and -B flags), rebuild ports recursively that depend on the port you specify (-r) and/or the ports that the port you're upgrading depend on (-R) and do lots of other nifty tricks.
One of the handiest flags that seems to get overlooked a lot is -o. -o is handy for making portupgrade upgrade ports predictably. Say you want to upgrade samba, but when you type "portupgrade samba" portupgrade wants to build net/samba3 instead of good ol' net/samba, which is what you really wanted. Use the -o flag to force portupgrade to replace the installed samba port with net/samba. It's as simple as "portupgrade -o net/samba samba"!
ports-mgmt/portmaster is like portupgrade, but nicer...It will do the recursive config of deps before everything else, download stuff in the background, is better at sorting out dependency issues, and so on. I've switched entirely to portmaster at this point.
I got tired of running pkg audit and portmaster separately, so I came up with a quick-and-dirty one-liner that pumps the output of pkg audit -Fq into portmaster. This will find ports/pkgs in the vulnerability database and attempt to update them via portmaster.
sudo pkg audit -Fq | sudo xargs portmaster
This little command saves me a fair amount of copypasta.
Sometimes you want to update software that has vulns listed by pkg audit. Portmaster won't permit you to update to a newer version of software that has known vulnerabilities, but there's a hack around that. Try adding -m DISABLE_VULNERABILITIES=yes to your portmaster command. This is not advisable for public-facing machines.
Occasionally I'll run into a FreeBSD machine that won't portsnap consistently any more, usually exiting with a message along the lines of "metadata is corrupt" for one of the downloaded portsnap files. The easiest fix I've found is to blow away /var/db/portsnap and start over:
rm -rf /var/db/portsnap mkdir /var/db/portsnap portsnap fetch updateas root.
PuTTY is a great little telnet/ssh client that also includes some very handy tools (pscp, psftp, pageant, etc.) that make life much easier as far as dealing with *nix machines from a Windows box is concerned.
I like to install PuTTY and friends somewhere on my Windows "Path" environment variable so I can run pscp/psftp from a cmd window, so a "quick and dirty" method to insure that everything is in a directory in your path is to install PuTTY or dump the files in to your C:\WINNT\SYSTEM32\ directory.
Having trouble seeing colors in your PuTTY terminals? Set your terminal-type string in the connection options to "xterm-color" instead of the default "xterm" and colors should work correctly.
Set your defaults. That 'Default Settings' saved session in PuTTY isn't there for just looks; you can set things to your liking there and new sessions will inherit those default settings. I prefer the courier font instead of courier-new, an orange cursor, disabling remote-controlled character set reconfiguration (under the features section inside the terminal features options) and such, so I save those to the 'Default Settings' profile early on.
From Tazle in irc.freenode.net's #2CPU comes a nifty trick for making URLs easier to copy with a single double-click (or less clicks) of the mouse. If you set certain characters in the "Control the select-one-word-at-a-time mode" window under the "Selection" option inside the "Window" option list to a class of "2" they can blend in with other "similarly-classed" characters and will automatically get included when you click on anything in the same class that touches those special characters. Tazle says he changed <, >, @, :, /, ?, &, = and "probably more" to class 2 and it makes URLs much easier to pick up with one double-click.
PuTTY is great, but if you'd like to use X apps on your headless server and don't want to hook up a monitor plus run X on the server itself, there's always Xming. Xming is an X Windows server that runs on Windows machines. Once you've got Xming and PuTTY configured properly, you can ssh to your server using PuTTY and display X apps on your local Windows box. Setting this up isn't difficult, but it did take me a bit to figure out...So I thought others may find it useful.
You've probably already got PuTTY installed, so just download and install Xming. Run XLaunch and accept the defaults. Save the config to the default name in the default location. That should be all you need for Xming config, but some things need to be checked in PuTTY.
In PuTTY, load a profile for a machine you want to use X apps on. Expand the 'SSH' category in the left side of the main 'PuTTY Configuration' window, then click on 'X11 Forwarding'. Make sure that there's a check in the box next to 'Enable X11 Forwarding' under 'X11 Forwarding'. Go back to 'Session' at the top of the 'Categories' list on the left side of the window, and save your session. That's all you need for PuTTY, but you need to make a few changes on the host you're connecting to.
On the host you'd like to run X apps on, edit /etc/ssh/sshd_config and add/change the following lines:
X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes
Changing these lines lets your ssh daemon forward X11 requests, sets a display offset, and lets the localhost name work in reference to the remote end of the connection. The last piece that's missing is xauth.
Install /usr/ports/x11/xauth. Just accept the default options.
Once that's all done, you should be able to connect via PuTTY and automatically have X app windows show up on the Windows machine you're running PuTTY on. You can just try 'xterm &' to test. I use this a lot for HandBrake.
At work I'm required to work with Linux quite a bit. I don't necessarily care for Linux all that much, but I found the colors that Red Hat and Fedora Core use for their "ls" output to be much more "clear" than the default FreeBSD "ls" colors. The FreeBSD "ls" doesn't use the same LSCOLORS format as Linux's "ls," so I had to come up with a close approximation of the Red Hat/Fedora Core color scheme. The closest I could find with only a few minutes' worth of work was
ExGxFxdxCxDxDxhbadExEx
Now all you need to do is toss that in your shell's rc file, exported properly, along with whatever you need to set "CLICOLOR" to YES for your shell. For sh (and derivatives), it'll look something like this:CLICOLOR="YES"; export CLICOLOR LSCOLORS="ExGxFxdxCxDxDxhbadExEx"; export LSCOLORSI think these colors are much easier to deal with and less drab than the default FreeBSD "ls" colors.
/usr/src is a handy thing to keep around. I know some users that delete /usr/src after doing their latest buildworld/buildkernel song-and-dance, ostensibly to "save some space." What it does, however, is make upgrading a much more painful process. cvsup will have to rebuild the entire tree, you can't apply patches to /usr/src if you need to patch cause, well, there's no /usr/src and you can't rebuild individual bits of /usr/src (like, say, sendmail) without cvsupping the whole mess, which will require you to do a complete buildworld/buildkernel to get everything back in sync.
It's more than safe to remove /usr/obj after doing the installworld/installkernel shebang, cause you can always build any dependancies you'll need to rebuild individual bits if you've got /usr/src around, but removing /usr/src is generally a Bad Thing(tm) unless something goes very wrong.
mplayer playing sound from DVDs horribly? Build multimedia/libdts from ports, then rebuild mplayer (using portupgrade -f). This fixed the occasional screeching racket sound from DVD playback. It only happens on certain DVDs, but when it happens it's annoying.
portsnap is a handy utility to update your ports tree quickly without cvsup. Benefits include being part of the base system (from 5.3 on, IIRC), being faster than cvsup and ease of use.
To use portsnap the first time, you simply run
portsnap fetch extract
to create the initial ports tree with up-to-date ports. Once you've done the (time-consuming) "fetch extract" step you can just use
portsnap fetch update
to update the ports tree with the up-to-date ports. The "fetch update" step is generally much faster than cvsup.
Looking for a quick and dirty way to test out all of your monospace, scaleable fonts in order to find one that looks better for you? Try this on for size:
fc-list :spacing=mono:scalable=true family | sort | tr '\n' '\0' | xargs -0 -I FONT echo xterm -fg white -bg black -cr orange -T \'FONT\' -fa \'FONT\' -fs 12 -e man ls \& > xterm_test; sh xterm_test
This will spew a bunch of terminals on-screen, all of them executing 'man ls'. You can change that if you'd like.
Need to build PHP5 with Oracle support? Check out this page. I've used this successfully at work and found the info on the page very helpful in getting things going.
Note that newer versions of PHP on FreeBSD do not play well with the versions of the Oracle ports listed in that guide. The guide is outdated and no longer applies to newer versions of PHP on FreeBSD...If you really need Oracle support on FreeBSD you can get it to work, but you'll be stuck with an ancient version of PHP.
Use mail/sa-utils, which adds a sa-utils script to /usr/local/etc/periodic/daily. You can add something like the following to /etc/periodic.conf to run the script and see the output as part of your daily maintenance e-mails...You do read them, right?
# SpamAssassin management daily_sa_enable="YES" daily_sa_compile="YES" daily_sa_compile_nice="YES" daily_sa_restart_spamd="YES"
This will keep SpamAssassin rules up to date for you, and let you know when new rules are downloaded/compiled/installed.
While fixing up a friend's server to support all the features that h5ai supports, I encountered an interesting problem. Apache 2.4 doesn't have /usr/local/bin in its $PATH. This is kind of annoying, cause h5ai uses 'which' to find some binaries located in—you guessed it!—/usr/local/bin. After much time spent figuring out the best way to set Apache's $PATH, I discovered that the rc script for apache (/usr/local/etc/rc.d/apache24) runs /usr/local/sbin/envvars, a script which executes scripts ending in .env located in /usr/local/etc/apache24/envvars.d, mostly used for altering the startup environment variables for Apache. So, creating /usr/local/etc/apache24/envvars.d/path.env and doing shell magic to $PATH in there will let you alter Apache 2.4's $PATH cleanly.
To sum up, just do something like this as root:
echo 'export PATH=$PATH:/usr/local/bin' >> /usr/local/etc/apache24/envvars.d/path.env
So, you've got your new network interface config set up in /etc/rc.conf and you're ready to test it out, but you're working via ssh and don't have console access to the machine? No problem! Be aware that issuing a standard netif restart as root will drop your interface settings and reload them from /etc/rc.conf, but doing so will also nuke any routes. This is definitely a bad thing if your only access is via the network. The easy solution is to restart both netif and routing in sequence on one line, like so:
sudo service netif restart && sudo service routing restart
I learned this one the hard way.
Page created 20040701 00:01 CDT.
Page updated 20180617 22:46 CDT.
Comments? Suggestions? Send them to hemi@puresimplicity.net.
© 2003 Josh Tolbert. This page may not be duplicated without
permission.