Troubleshooters.Com and Steve's BSD Resources Present

FreeBSD: Initial Lessons Learned

Copyright (C) 2012 by Steve Litt, All rights reserved. Material provided as-is, use at your own risk. 




CONTENTS:


Introduction

For years I've wanted to investigate a BSD desktop, and have heard that for desktop activities, FreeBSD is wonderful. So during the first GoLUG/FamiLAB Buildfest, which took place on 9/15/2012, I researched FreeBSD, the Awesome window manager, and the Weechat IRC client. This document lists most of what I learned at the Buildfest and the few days afterward. The idea of this web page is to give a Linux-confident person the additional info he or she needs to run a FreeBSD desktop.

For me as a 14 year Linux user, using FreeBSD is like one of those weird dreams in which you know you've been here before, you kinda-sorta know your way around, but things have changed. Being a Linux guy, I automatically had just enough FreeBSD knowledge to make me dangerous. I also picked this particular time to start using the Awesome window manager. From my perspective, Awesome is to Xfce as a stick shift is to an automatic.

One last thing. You might be waiting for me to rule on FreeBSD as a desktop. From the few days I've logged with FreeBSD, my opinion is it's definitely ready for prime time on the desktop. It runs Claws-Mail, OpenOffice, graphical Vim, Komposer, Gnumeric, Firefox, LyX, and most other desktop apps I need for business.

FreeBSD doesn't easily accommodate Flash, and therefore Youtube movies. From what I read on the Internet, it can be done, but my experience is it's hours of painstaking, trial and error work, if it can be done at all. I couldn't do it. So what? When I go out on the road, I'm using my computer for business, not to watch movies.

So let's get started...

LESSONS LEARNED: FreeBSD

If you want a regular user to be able to use su and sudo, you need to make that user a member of group wheel. Then, in every newly logged in terminal, su and sudo will work.

Be forewarned, if you're a Linux guy, especially one used to a "kinder and gentler" Linux like Mint or Ubuntu, at first FreeBSD will seem like a broken Ubuntu, with some truly maddening unexpected behaviors. I think if you suspend judgement until you've read this document and logged a few hours with FreeBSD, it will make more sense, and you might even like it.

Shells

In a default FreeBSD installation, the default shell for regular users is sh, and the default shell for root is csh. The shell makes some subtle differences in the way command completion works, so you need to be aware of it or you'll draw wrong conclusions about what's installed on the machine and whether an install succeeded or failed. When in doubt, try running it explicitly from /usr/local/bin.

NOTE: The csh shell caches various things, which is why it often can't pull up a just-installed program. To fix that problem, a lot of times you can just run csh's rehash builtin command.

Installation

When installing FreeBSD for the purpose of learning what you're doing, I suggest doing it on its own computer, and taking all the defaults. This gives you maximum chance of success. As you get better at FreeBSD, you can customize your installation.

I installed FreeBSD by taking over the hard disk and basically agreeing to all the defaults, so I can't give much guidance on the OS' installation. What I can do is give pointers on installing programs on a running FreeBSD system.

FreeBSD has two ways to install a program:

  1. pkg_add -r package_name
  2. From ports
The pkg_add method is much quicker, so I'd recommend using it first. If it fails to install or if you don't like the configuration of the installed program, then you can install from ports.To install from ports, find the desired program in the /usr/ports tree (find | grep is your friend), and run make and then make install within that directory. Be aware this is much, much, much slower than pkg_add. Another good thing /usr/ports does for you is it can tell you exact package names to use with pkg_add.

NOTE: Later in this article I'll describe alternatives to find . | grep.


Finding Package Names

Using find . | grep was already discussed, but there are other ways to find a package name. One is to pull up the Latest web page for your BSD version. For instance, right now I'm using 64 bit FreeBSD 9.0, so I would pull up

Another way is to use make search name or make search key from the /usr/ports directory:
The first command looks for any port containing the string "openoffice" in its name. The second command looks for any port containing the word "spreadsheet" in any of its keywords, showing you all the spreadsheets and also other software.

Be aware that before you can use the make search construct from /usr/ports, you must have an index. You can make the index with one of the following commands, executed within /usr/ports:
The former command builds an index based exactly on your current /usr/ports tree, and takes a long time (like a half hour). The latter takes much less time because it downloads the index from the Internet, but might not faithfully represent the current state of your /usr/ports tree.

LESSONS LEARNED: FreeBSD Wifi

When you install FreeBSD, try to use wifi instead of wired. This way, if your installation succeeds, you're guaranteed to have your wifi set up to at least receive signals and expose the right interface (wlan0 on my Atheros-equipped laptop). Sure, installation takes longer on wireless than on wired, especially gigabit wired, but the savings in wifi setup can more than make up for it.

If you install via wifi, it's likely that your wifi will still work upon reboot. However, if you go somewhere else with different wifi, it almost certainly will not, and will fail without informative feedback. This subdocument tells you what to do.

Unlike Linux, which has bunches and bunches of Wifi specific commands, in FreeBSD you do almost everything with ifconfig. You'll also need the wpa_supplicant command and /etc/wpa_supplicant.conf. Your first task is to make sure at least your wifi NIC's Radio Frequency (RF) is working by issuing the following command:
ifconfig wlan0 list scan
The preceding should give you a list of Wifi transmitters, with their SSID names.

From here on, the wifi steps should be done as root...

The previous tells you what's transmitting in the vacinity, and what encryption (or lack thereof) each is using. Unfortunately, it tells you nothing about reception quality, making it hard to choose the best.

/etc/wpa_supplicant.conf should contain the following lines at the top:

ctrl_interface=/var/run/wpa_supplicant
eapol_version=2
ap_scan=1
fast_reauth=1

Each WPA encrypted network recognized by this computer must have a network block written in /etc/wpa_supplicant.conf:

network={
        ssid="mywifi"
        psk="mywifipassword"
        priority=5
}

After writing that into /etc/wpa_supplicant.conf, energize the device:

/etc/rc.d/netif stop
/etc/rc.d/netif start

If that doesn't connect, then in a separate terminal, as root, do the following:

wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf

In the preceding command, substitute whatever wifi device you have for my wlan0. Once you have your network and passwordkey in /etc/wpa_supplicant.conf, the netif  start command should run wpa_supplicant, but if it doesn't, you can run it manually.

Sooner or later you'll hit the road and need to connect at unencrypted restaraunt or hotel hotspots. No problem, put something like the following in your /etc/wpa_supplicant.conf:
network={
ssid="Bates_Motel_Wifi"
key_mgmt=NONE
priority=5
}
The line saying key_mgmt=NONE says it's wide open, and not to use a password.

Ubuntu has a nice little applet to select a Wifi network. Not so for a FreeBSD laptop. So, to switch to another Wifi, put that Wifi's network block in /etc/wpa_supplicant.conf, and then stop and restart wpa_supplicant as shown earlier in this article.

Now the cool thing is, you can get a FreeBSD port called wifimgr that's a nice GUI program to detect and connect to various Wifi transmitters. I'd suggest you do that, unless you have a reason to do it manually with wpa_supplicant.


LESSONS LEARNED: Awesome


Awesome is a window manager intended to be keyboard-centric, and really makes sense only if you have a good command over its hotkeys. Most hotkeys involve the Windows key plus a letter, possibly plus another modifier such as Shift or Ctrl. Here are the most common ones:


There are many, many more hotkeys, but if you know these hotkeys, 90% of your work will be with the keyboard, and when necessary, you can do the other 10% with the mouse. The hotkeys listed above make Awesome bearable.  Then, as you use it, you'll learn more and become efficient.

To change Awesome's default terminal emulator, go into /home/yourname/.config/awesome/rc.lua, and change the term= line to the desired terminal emulator; rxvt, for instance. To change the theme font (the one on the little bar at the top, go into /themes/default/theme.lua and change theme.font.
To change the rxvt font, go into .Xdefaults and change the URxvt*font: line to 10x20, or whatever size you want.


LESSONS LEARNED: Other Desktop Environments

It's easy to install Xfce and/or LXDE via ports or pkg_add -r. Both are excellent with FreeBSD. My perception is that although Xfce is lacking certain features on FreeBSD, such as the battery applet and the network applet,  it appears more stable on FreeBSD.

LESSONS LEARNED: The Mousepad

I can't be the only one. I get down to typing, my palm hits the mousepad, a couple of paragraphs in my document get highlighted, and then replaced by my next keystroke. There's GOT to be a better way.

This article has three ways, one of which is to some extent a security risk.

The Insecure Method

We'll start with the security risk first...

Compile the following C program, call the result pad_asroot.bin, place it in /usr/local/bin, and chmod it 4755.
#include <stdio.h>
#include <stdlib.h>    /* Required for system() */
#include <unistd.h>    /* Required for setuid() */
#include <string.h>    /* Required for strcasecmp() */

/*
   NOTE: if strcasecmp() isn't supported, try stricmp() or strcmpi()
   Otherwise, write your own with a for(;;) loop.

   NOTE: To function properly, the executable made from this C program
   must be set setuid root (chmod 4755 a.out).

   SECURITY NOTE: Don't you dare allow user input to get run as a
   command, but instead make it like this program, where user input
   is used to determine which of several predetermined commands is
   run!
*/


int main(int argc, char *argv[]){
    char *thearg;

    if(argc != 2){
        printf("Error, must have exactly 1 arg, either enable or disable\n");
        return(1);
    }

    thearg = argv[1];

    if (!strcasecmp(thearg, "disable")){
        setuid(0);
        system("ps ax | grep psm0 | grep -v grep | cut -b 1-5 | xargs kill");
    } else if (!strcasecmp(thearg, "enable")){
        setuid(0);
        system("/usr/sbin/moused -p /dev/psm0 -t auto");
    } else {
        printf("Error, argument must be either enable or disable\n");
        return(1);
    }

    return 0;
}

Once that's done, to turn the mousepad off, do this:
pad_asroot.bin disable
And when you want to turn the mousepad back on, do this:
pad_asroot.bin enable
This solution is a security risk, because when you did chmod 4755 pad_asroot.bin, you did setuid root on this program. Now a badguy can come along, change the LD_PRELOAD environment variable to a directory with his special version of printf() or other library function that installs a program that's really a setuid root shell, and the next time he logs in as a normal user he can escallate himself to root.

Don't use this method unless you have a VERY good reason to -- you'd be inviting badguys onto your computer and the network to which it's attached.

The sudo Method

Put the following pad_disable.sh, owned by root and in group wheel, into /usr/local/bin:
ps ax | grep psm0 | grep -v grep | cut -b 1-5 | xargs kill

And put the following pad_enable.sh, owned by root and in group wheel, into /usr/local/bin:
/usr/sbin/moused -p /dev/psm0 -t auto

Using visudo, put the following two lines in your sudoers file:
slitt ALL = (root) NOPASSWD:  /usr/local/bin/pad_disable.sh
slitt ALL = (root) NOPASSWD: /usr/local/bin/pad_enable.sh
Obviously, substitute your own login name for slitt.

Now, to disable the mouse, do this:
sudo pad_disable.sh
To reenable the mouse, do this:
sudo pad_enable.sh
This method works both in CLI and in X.

The only thing wrong with this method is that some FreeBSD systems might use something other than /dev/psm0, and if they do, this method won't work. Also, if some other process includes the string psm0, it would be killed by the pad_disable.sh script.

The synclient Method

If you can get this to work, you've got me beat. Anyway, there's a package at:
/usr/ports/x11-drivers/xf86-input-synaptics
If you install that package, you get the synclient executable and the syndaemon daemon. Theoretically you can get those to shut off the touchpad every time you type, and have it remain shut off for a certain period after your last keystroke, which minimizes problems where your touchpad first selects text from your document, and then your next keystroke replaces it.

Trouble is, I couldn't get this to work. There are all sorts of conflicting methods on the Internet. If you run across the method telling you to run sysinstall and change the mosue, think VERY carefully before doing that. You can mess up your mouse (or perhaps other config items) in ways that take some real thought to put back the way they were. From what I saw, sysinstall does not come up with the current config option highlighted, but instead highlights the first one, meaning if you accidentally accept a setting, you've probably just changed it and don't know what it was originally.

My opinion: If you can get the sudo method to work, that's good enough. Why risk heartache and misconfiguration?

LESSONS LEARNED: ssh

When trying to use ssh with X  forwarding (ssh -X) to or from your FreeBSD computer, you may get the following error when trying to run a GUI program on the remote computer:
X11 connection rejected because of wrong authentication.
xterm Xt error: Can't open display: localhost:10.0
One way to eliminate that error is to use the -Y parameter instead of -X, which enables trusted X forwarding and thus eliminates the X11 security extension controls. In other words, use ssh -Y instead of ssh -X. That's good for a quick and dirty test. If you're going to be sshing between these two machines a lot, you should probably solve the problem in ssh_config and sshd_config, if possible.

Be aware that on the Internet I've seen posts saying these errors are caused by a bad glibc, and advising you to downgrade. I see that as a very bad move.




Back to Troubleshooters.Com * Back to Steve's BSD Resources