15. Getting Started With FreeBSD and Unix
Introduction to FreeBSD
15.1.   User Names and Passwords -- Logging In
15.2.  The SuperUser - root
15.3.  The Unix Environment
15.4.  Changing Passwords
15.5.  Creating/Adding Users
15.6.  Unix System Commands
15.7.  Erase and Kill Characters
15.8.  Shutting down FreeBSD

15.1.   User Names and Passwords -- Logging In

When you boot FreeBSD, you'll see the hardware detection messages scroll by on the screen, followed by some information that indicates what daemons are being started. When everything is said and done, you'll be left with ``The Login Screen''. It will resemble the following:

If you've never used a multi-user operating system before (DOS, Windows, and Macintosh are all single user.) the concept of ``logging in'' will be new to you. FreeBSD is waiting for a login - a login is simply the name that you supply to FreeBSD to identify yourself to the operating system. FreeBSD keeps track of which names are permitted to log in or access the system, and only allows valid users to have access. When you successfully log in, you'll be presented with an interface to the operating system - the Unix Environment covered later in this chapter. Generally login names reflect a person's real name (for example, on my home system my login name is mark on a larger server at the University, my login name is mmayo - to distinguish me from all the other Mark's on the system). Login names must be unique on a particular system.

To gain access to the system, you type in your login name. If you are booting FreeBSD for the first time, the only account that is valid is that of the SuperUser: ``root''. Type root at the Login: prompt and press ENTER If you specified a password for root during the installation you'll be asked for it now; otherwise the system will immediately log you in as root. If you are new to Unix, you would be wise indeed to read the section entitled The SuperUser presented later in this chapter.

Things to remember:

  • FreeBSD login names and passwords are case-sensitive. Root is different than root, ROOT, and rooT. With out strong reasons, it is suggested that you use all lowercase for your user names, keeping them to 8 characters.

  • The root login does not restrict you in any way. You are god of your OS. With one simple command, you could wipe out everything! Cool huh? For this reason, use the root login only when necessary. Avoid experimenting with commands when you are root.

  • System administration is another term you will see often. A system administrator is the actual person who sets up and maintains the FreeBSD (or any other) system. You are the system administrator of your home PC, but your roles (fortunately) are far less consuming than the system administrator of a large public server. System administration generally requires SuperUser privileges.

One of the most useful things about FreeBSD is that you can ``log in'' from just about anywhere! FreeBSD uses the notions of ttys - ``terminals'' that can attach to a virtual terminal (ttyv - such as your screen), a pseudo terminal (ttyp - such as a network connections from another Unix or Windows computer), and serial terminals in case you happen to have an old DEC vt100 terminal device lying around :-) Terminals, combined with the concept of logging in make FreeBSD/Unix a dream to administer remotely! Another side-effect of the multi-user ttys is that YOU can be logged into your own system as many times as you want. If you've just started FreeBSD for the first time, then it may not be obvious too you how to get multiple logins going at the same time. It's easy, just hit ALT-F2 to switch to ``virtual console 2'' and you'll see another login screen. By default, FreeBSD ships with 3 virtual consoles (ttyv0-2), reachable with ALT-F1,ALT-F2,ALT-F3. Go ahead and try switching between consoles! Having multiple sessions (logins) going can be extremely useful. For example, say you want to search for the word ``foobar'' in the entire /usr/src source tree! Depending on the speed of your disk and CPU, this could take quite a while - say 2 minutes - so instead of waiting around doing nothing while the command grinds away, you can switch to another console and continue working on whatever you want.

Logging Out!:

Logging Out!

When you're done doing whatever you were doing it's time to log out! You can either type logout or exit. Once you've logged out, you'll see the Login: prompt again, indicating your system is ready for more abuse :-)

Note:

The term ``account'' is synonymous with ``login'' Some people use the phrase account to encapsulate a user's entire set of rights and possessions on the system (his login permissions, files, home directory, mail account, etc.), and use the term login to refer to the user's ``account name'' At any rate, the two terms can be used interchangeably and their exact meaning varies depending on who you talk to :-) For clarity, we will always append ``name'' after account or login to indicate we're only talking about the user's login name...

15.2.   The SuperUser - root

In FreeBSD (and just about all other UNIX systems) the superuser login name is root. No matter how large or small the system may be, if you can login as the user root, the system is wide open for you to do whatever you please. Obviously, letting anyone log in as root is a Bad Thing(tm). Remember, root can do *anything*. Only you should know root's password.

To prevent unauthorized access, the root login should always have a secure password. By default, in FreeBSD, root does not have a password; it's up to you to change it. The trick is picking a good password. It's been known for quite some time that people tend to pick passwords that they can easily remember (we're humans, after all): their birthday, their home town, an item on their desk, and so on. The problem with these passwords is that they are easy to break, either through guessing or by more sophisticated methods of attack.

So picking a ``good'' password is important if your machine will be connected to a network (a LAN, or the Internet). The best passwords combine a mixture of Upper and Lower case characters, as well as numbers. A fine example would be: 34DodgesU, or Beezl891. It's even better if there are no ``real words'' in your password, since one common form of attack is to exhaustively try common combinations of words and numbers against your password entry. Personally, I think a password should be pronounceable, since it minimizes the risk that you might forget it. Try memorizing S8t4WxlT43Dc23HiiU2 and you'll see what I mean...

Finally, perhaps the best approach to password privacy is to never write your password down, and to change it every so often. There are system administrators that change their (and root's) password several times per week. Many people recommend a more reasonable time frame of 2 to 3 months.

Also remember that you should only be the SuperUser while you are performing System Administration tasks. For 'normal' activities, it's always a better idea to do them as a mere mortal since mere mortals can't wipe out the entire operating system so easily.

To ``become'' the SuperUser while you're a normal user, you need the command su. su stands for ``switch user'' and you can use it to su to any other user on the system. If you just type 'su' by itself, it is assumed that you want to su to root - the SuperUser.

Warning:

In FreeBSD, you must be in the wheel group to su to root.

So go ahead and put yourself in there now. If you have no idea what I'm talking about, just wait until we get to the section ``Creating/Adding Users'' and it will all be explained.

15.3.   The Unix Environment

15.3.1.  The SHELL
15.3.2.  The UNIX Philosophy
15.3.3.  Using the TCSH - a walk through a day on the command-line

The Unix environment, for the most part, involves two aspects:

  • The Shell

  • The User Environment

I can't really tell you exactly what the Unix environment is - but I can tell you what most people believe contributes to "it". Really, the Unix environment is just FreeBSD's interface onto itself. Huh? Think of it this way: You need to get things done and the operating system is willing and ready to perform these tasks. However, you need a way to talk to FreeBSD before you can go anywhere. The "Unix Environment" is the collective services, features, and ideologies that represent the interface to the operating system. If you want to work with FreeBSD (or any Unix for that matter), you need to use the Unix environment to get your work done. As we will see, the Unix environment not only ``lets'' us get our jobs done, but influences how we approach and solve problems. I'll talk about this philosophy of design after a brief introduction to ``The Shell'' We will end up this section with a hands on walk through of how to use the shell, and the rest of the Unix Environment.

15.3.1.   The SHELL

The most visible part of the Unix system -- the part that prompts you for commands and appears to do your bidding is the shell. A shell is a user interface: it talks to the Operating System for you and grants each logged in user system resources (like processor time, disk storage, memory, etc.). The primary purposes of the shell are to provide prompting, command interpretation and execution, and error reporting. You tell the shell what you want done by typing in commands after the prompt. It's very similar to the command interpreter under DOS, but infinitely more powerful and functional. Instead of presenting users with "C:>", most Unix shells present you with "$" or "%". Naturally, the prompt can be changed - more on that later!

There are many different Unix "Shells" available. By default, most people will be using the ``C Shell (csh)'' under FreeBSD. You can tell if you are using this shell if your command prompt has an "%" in it. The C Shell is thus called because it is modeled after the C language syntax. For added functionality (including command line editing and an interactive ``history'' mechanism), you can use "tcsh", which has become quite popular and has very similar syntax to csh. Also available are the Bourne Shell (sh) and the Bourne Again Shell (bash). bash is the default on Linux systems, whereas tcsh or csh are generally the defaults on BSD systems. Finally, there is also the Korn Shell (ksh) written at Bell Labs - ksh has become a de facto standard on System V based UNIXes. There is a free implementation called "pdksh" (public domain ksh). Many people consider the tcsh the most feature rich, but that doesn't mean it's right for you. The only way to know for sure is to try them all out and see which one turns your crank. tcsh, bash, and pdksh are all available in the FreeBSD Packages Collection.

Note:

Although you spend most of your time in what's known as the ``interactive shell'', most shells also provide a high-level programming language (scripting language) that is typically used to automate mundane day to day tasks. That being said, Perl is quickly replacing this use of shell languages in many sysadmin circles, and for this reason we will only look at the shell from an interactive stand-point. If you do want to get into shell programming, there are many books available on the subject!

15.3.2.   The UNIX Philosophy

Before we get started with how to maneuver around your system with a shell, we need to get several things out of the way first. When the powers that be created Unix, they had a certain idea, or goal, about how it should work. This is loosely referred to as the "Unix philosophy". It can be summed up in the simple phrase: "Small is beautiful". The philosophy has grown from the UNIX community instead of being forced upon it. According to Mike Gancarz, in ``The UNIX Philosophy'', there are 9 major ``tenets'' of the Unix philosophy. Several are significant to your understanding of how to make the most out of your FreeBSD system:

  1. Small is beautiful

  2. Make each program do one thing well

  3. Make every program a filter

The idea here is that small programs are simple, and therefore easier to understand. A natural side effect is that a program should only do one thing - if you want more than one thing done, you just connect different individual programs to accomplish your task. That's where filters (also referred to as pipelines) come into play. Every program is a filter in the sense that it produces an output given an input. The output of one program can be fed into the input of another program, and vice verse. You will see what I mean once we get to some concrete examples in the next section.

15.3.3.   Using the TCSH - a walk through a day on the command-line

Personally, I use tcsh as my shell, and for this reason we'll focus on this shell in particular as we walk through several examples of how to take full advantage of your shell. tcsh is a modified version of the C Shell (csh). It's fully backward compatible with csh, but it has many new features that make user interaction much easier and more efficient. The biggest areas of improvement are command-line editing, and history navigation. For me, these make life on the command-line much more enjoyable. Everything we'll say about input and output redirection, pipelines, prompts, and job control is identical to the standard csh. If you don't have tcsh installed on your system (just try typing 'tcsh' to find out) then you can add it from the Package Collection.

Pipes and Filters

tcsh provides a mechanism to connect programs together - the filter mentioned above. It is called "the pipe", to represent the directional flow of data "through the pipe". With tcsh, the pipe is represented with the "|" character. Before we can use a pipe, we need to know two UNIX commands: who, and wc. who gives a list of each user that is currently logged onto the system, while wc counts words. Let's say we want to find out how many users are on the system. Here's how you ask:

vinyl % who | wc -l

8
vinyl %

Whoah! There's quite a bit going on here. First of all, you should recognize that the "vinyl %" is my interactive prompt (I've made a simple modification to the prompt to let me know what machine I'm on - in this case ``vinyl''). It's begging me for commands, and I fed it the command "who | wc -l". The answer was 8. Let's take a closer look at what happened. Normally, the command who by itself would perform like this:

vinyl % who
mark	ttyp0	Jun 20 18:04	(131.111.238.108)
dlow	ttyp1	Jun 9 10:53	(204.27.111.42)
chrisc	ttyp3	Jun 20 17:46	(208.8.24.42)
gabor	ttyp4	Jun 19 13:10	(206.222.78.163)
.
.
.

vinyl %

Notice that there is one user per line. We want to take this result and do something with it. In this particular case, we want to count the number of lines, which will be the equivalent of counting the number of users currently online! So what we do is ``pipe'' the result of the who command into the wc command. wc sees the output of the who command as its input, and processes it. The final thing to note is that we gave the wc command a "command line option"; the -l part. "-l" simply tells wc to count lines instead of words. The example above demonstrates quite a bit about the UNIX command line. If you're confused, the best way to learn is by picking a few commands and experimenting. One of the most common uses of the pipe on the command line is with the programs "more", or "less". Anytime a program gives an output result that is more than a page long, the best way to view it one page at a time is to pipe the result into more. For example: last | more. This lets me see the output of the command last ( which outputs a list of all the users who have "last" logged onto the system) one page at a time. Quite useful indeed.

Command Completion

Command completion exists in the tcsh to make your life easier. With command completion, the shell is able to determine which files you are interested in on it's own. It will become clear what I mean once you see the following example. Remember the the cd command "changes directories". Lets say you have the following directories and files in the current working directory:

vinyl % ls -F
News/	bin/	code/	games/	mail/	resume.ascii	test/

If you want to change directories from the current working directory to the test subdirectory, you would enter the command:

vinyl % cd test

With command completion, you can save on your typing by recognizing that the directory name 'test' is uniquely identified by the its first letter, 't'. So all you need to type is:

vinyl % cd t<tab>

The <tab> is of course the actual tab key found on your keyboard. When you hit the tab key tcsh will fill in the rest of the filename for you! This can be a real help with longer file names and makes moving around on the command-line much quicker. Instead of the Tab key, and the standard csh uses the ESC key.

Wildcards

Wildcards allow tcsh to match more than one file at a time. It supports the three standard file wildcards supported by pretty much all shells:

  • * matches any character or any number of characters

  • ? matches any single character

  • [...] matches any single character contained within the brackets

The * wildcard can be used to do the same thing as command-completion above. If you entered a command like

cd t*

and only one subdirectory in the current working directory begins with the letter t, this command would behave the same as if you had used command-line completion by pressing the Tab key. The * matches any number of characters, so in this case it will match anything behind the leading t character, such as 'test' from the example above.

A more common use of wildcards is for working on multiple files however. Often the ls is used as follows:

vinyl % ls -l *.html

This will show you all the files that end with '.html' -- your web pages. The best way to get a feel for wildcards is to just play around with various combinations. Look at the results and figure out how the command behaved. After a very short period of experimentation I'm sure you will have wildcards mastered!

Command History

All the commands you have recently typed are stored in a file named .history and located in your home directory. The command h will show you a list of the most recent commands you have typed. All the commands are numbered. You can repeat a command by typing an exclamation mark, followed by the command number you wish to execute. For example: !22 would execute the command number 22 from my history list.

Sprucing up TCSH's default behavior

Both csh and tcsh read configuration files when they start - .cshrc and .tcshrc respectively. tcsh will also read the .cshrc file if no .tcshrc file is present. You can customize the behavior of the shell, and set environment variables in the startup files. Remember that you need to use ls -a to see files that start with a period!

Skip ahead to the Sample Configuration section for an example of a typical .tcshrc and .cshrc config file.

15.4.   Changing Passwords

Changing passwords in FreeBSD is quite simple. It is accomplished with the command passwd. When you type in the command you get:

Note that my first two attempts at a new password were not accepted. First, I picked a password that was too small, and then I picked a password that was all lower-case letters. Both passwords are easy to guess or crack, so FreeBSD refused to let me choose such weak passwords. My third attempt was more than 6 characters, and was a mix of upper and lower-case letters - that one worked. After you enter a suitable password you are asked to retype it to make sure you didn't make a mistake. That's it!

If you are root, you can change anyone's password (although you can never learn what someone else's password is) by typing passwd fred (for example). As root, you can also insist on an insecure password by ignoring the warnings. If you're on your home machine, and it's never connected to the Internet, this is probably fine.

The other related command you might want to investigate is chpass. It will let you set things for your login like what shell you want to run, your full name, and what your Office and Home phone numbers are!

Finally, if you ever want to make changes to the password file directly, you use the simple command vipw. Note that this stands for ``vi password'' which implies that you can get around in vi. (In case you were wondering, vi is an excellent text editor that is pretty much the standard on all UNIX Operating Systems - we explain it in full later on in the book.) It's a good idea to see what the password file looks like, and after you're comfortable in vi please try this command out. As with all the FreeBSD password utilities, if you do make a change, vipw automatically rebuilds the password database for you. On newer FreeBSD machines, ee, is the default editor for root. This can be changed by editing the EDITOR variable in your default .cshrc file.

15.5.   Creating/Adding Users

Adding users in FreeBSD is simple, since there is a handy little system command that does all of the work for you: adduser. Adding a user to a system involves setting up a few things, and before we step through the adduser command, it would be best for you to know exactly what has to change on your FreeBSD system for a user to ``exist''

  • First of all, FreeBSD must know what users are allowed to login, and what their passwords are so it can validate the login requests. All of this information is stored in the ``password file''. A plain text version of this file, suitable for human consumption, is located in /etc/passwd. Go ahead and take a look at this file (type cat /etc/passwd). You should see a bunch of lines that look a lot like:

    dirk:*:1061:1061:Dirk Jessberger:/home/dirk:/usr/local/bin/tcsh

    This line contains most of the information needed about the user named ``dirk'' The line is separated into separate pieces of information by the : character. The first part should be obvious - it's the ``user name''. The next two numbers are the ``user id'' and the ``group id''. Every user in FreeBSD belongs to a primary group (and as we will see below, can belong to many secondary groups). The next section is dirk's full name, ``Dirk Jessberger'' The last two sections say where dirk's ``home directory'' is (the location on the file system that belongs to him), and what shell FreeBSD should start for him when he logs in.

  • Information about what other groups dirk belongs to, as well as the name of his primary group (group pid 1061) is stored in the ``group file'', which you can view by typing

    cat /etc/group. You see lines like this:

    dirk:*:1061:dirk
    geeks:*:1023:mark,tburgess,sarahs,jgturner,pwardrop,gabor,karen

    The format is similar to the password file, and in this case the first section of the line says that the group called ``dirk'' is known by the ``group id'' 1061, and the user ``dirk'' belongs to this group. In other words, the user dirk belongs to his own group: dirk. This is the default - users have their own groups. You'll see in the second line, however, a group called ``geeks'' with ``gid'' (group id) 1023, and a whole bunch of people who belongs to the group ``geeks'' A little later, when we deal with file permissions, we will see why this type of situation might be desirable.

  • Finally, when a user logs in, they need a ``home directory''. A home directory is owned by the user, and is ``where you put your stuff''. Your home directory also holds your ``dot files'', which are config files (such as .cshrc) that tell various programs how to behave. In FreeBSD, user home directories are usually located in /home.

Now that we've seen what FreeBSD needs to know in order to host a user, lets take a look at the program adduser. Adduser checks the passwd, group, and shell databases (which are built from the text files mentioned above) when adding users to make sure everything is valid. Adduser also creates a passwd/group entry for the user, a HOME-directory, dotfiles and sends the new user a welcome message! As you can see, the adduser program does pretty much everything for you, and saves a lot of time compared to the old method of manually setting up an account for a new user.

Adduser is an interactive program, meaning that by default you start it up with no arguments (command-line options) and it asks you questions, which you answer, until it has all the info needed to add the user to your system.

15.6.   Unix System Commands

Start in Late July.

15.7.   Erase and Kill Characters

Start in Late July.

15.8.   Shutting down FreeBSD

FreeBSD is a sophisticated, multi-user, multi-tasking operating system. It's not DOS. You can't simply ``power off'' with the power button on your PC without first telling FreeBSD that you wish to shutdown. If you want to know why, continue reading. Otherwise, just skip ahead to the next paragraph for the necessary commands. When your FreeBSD system is up and running, it goes through a lot of measures to optimize performance. One of the biggest ways to optimize performance is through the use of ``buffers''. When you read or write to the disk, data is moved into and out of buffers. You can think of buffers as buckets. Lets say I have a hose running, and it only reaches so far. Unfortunately, I'm still 5 meters away from my pool, and I need to get water into the pool. Obviously, it's not very efficient for my to take one glass of water at a time from the hose over to the pool. I'd use a bucket - or more precisely, I'd place the bucket under the hose, and when the bucket fills up I'd dump it into the pool. Get it? The FreeBSD equivalent is: it's slow to write to the disk, so I want to minimize the trips I have to make to the disk. So when I'm writing a file, I place the information I need into buffers until I have enough to make it worth while to go and visit that slow old hard-disk. Then I can write everything out at once. Since buffers are stored in RAM, if you just cut the power to your computer, there is a chance that some of the information you thought you wrote to the disk never actually made it there! And that would be crappy. As it turns out, FreeBSD (actually, the filesystem FreeBSD uses) ``syncs'' data from the buffers out to the hard disk every 30 seconds - but even then there is no guarantee that sync will move it to the disk right away. If the system is under low load (a measure of how busy the CPU is - usually very low on a workstation, but it could be quite high on a multi-user server) then it's unlikely that data will be sitting in a buffer for more than a couple of seconds. So, you need to tell FreeBSD to take whatever is sitting buffers and dump it to the disk. Hence, the shutdown command. It slices, it dices, it sync's, and it notifies! What more could you ask for?

To shutdown FreeBSD, you use the shutdown command! Depending on what arguments you give it, it will behave differently. For example:

shutdown -h now Tells FreeBSD to shutdown, halt the CPU, and do it now.

shutdown -r now Tells FreeBSD to shutdown, and then reboot the system. Do it now.

reboot Does the same as shutdown -r now.

When you do the shutdown command, a broadcast message will be sent to all users currently logged in that the system is going down. Instead of ``now'' you could say shutdown -h +5 which will bring the system down in 5 minutes. Every minute FreeBSD will send a broadcast message to all users warning of the impending shutdown. If you just want to kick everyone off, shutdown -k now will do so, and will also prevent anyone else from logging in!

In summary, using the FreeBSD shutdown command is not only the ``safe'' way to stop your system, but also the ``friendly way'' :-)

 

Return to Table of Contents

Visit the Gifcom