InformIT: Mac OS X Unleashed > Appendix B. Administration Reference

Table of Contents

Appendix B. Administration Reference

This appendix contains a number of useful modifications that you might want to make to your OS X environment. These suggestions range in urgency from "If you don't do this, you're in danger of a typo trashing your whole machine," to "We think this is a relatively cool enhancement that you'll probably like." We've listed these in what we feel is the order of importance for each to be implemented.

Fix rm so that it always runs in interactive mode

As root, edit /etc/csh.login or /usr/share/init/tcsh/login and add a line like the following:

alias rm rm -i

You could add it to your home directory .cshrc file or, following Apple's odd convention for providing shell preferences, to the login.mine or aliases.mine file in ~/Library/init/tcsh/ instead. But if the line is put in either of these locations, it will apply only to you as a user, rather than to every user of your system.

After this modification is made, rm will prompt for confirmation before removing any files. If you want remove many files without being prompted for confirmation, escape the rm with the shell escape \ and add the -f (force) flag for good measure. That is, issue the command as \rm -f <files> , instead of rm <files> .

Turn on access to the root account

Refer to Chapter 11, "Additional System Components," for instructions how to do this in one of several different ways. You'll need the root user enabled, or you'll have to continually jump through some annoying validation hoops to perform a number of tasks in this book. We recommend that you use the root account only in very limited circumstances. But the use of the sudo command for all root-requiring work, as being promoted in many Internet OS X forums, provides just one more avenue for error and frustration.

We've provided copious cautions regarding the best use of root throughout the book, and we do want you to understand that that account has amazing power over the system. Use it carefully, but don't be afraid of it.

Add directories to the system's path

Add the current directory, ./, to your $path shell variable. This will allow you to execute commands that are located in your current directory without typing ./ in front of the command name.

If you want to make this change for all users on your system, edit /usr/share/init/tcsh/login. Change the section of code that says

set path = (                                                                    ~/bin                                                           /usr/local/bin /usr/bin /bin                                    /usr/local/sbin /usr/sbin /sbin                            )

so that it says

set path = (                                                                    ~/bin                                                           /usr/local/bin /usr/bin /bin                                    /usr/local/sbin /usr/sbin /sbin ./                         )

While you're at it, you might want to add another directory. It doesn't have any executables in it now, but we'll be adding applications to it in Chapter 17, "Troubleshooting Software Installations, and Compiling and Debugging Manually." Extend the path further to

set path = (                                                                    ~/bin                                                           /usr/local/bin /usr/bin /bin                                    /usr/local/sbin /usr/sbin /sbin                                 /usr/local/netpbm/bin ./
           )

Whenever you extend the path, always make sure that the current directory, ./, is the last thing in the path.

If you prefer to make these changes for your own account only, add the following to your home directory .cshrc file (or ~/Library/init/tcsh/tcsh.mine):

set path = ($path ./)

Or, to add the netpbm directory as well, add the following:

set path = ($path /usr/local/netpbm/bin ./)

Tweak your user environment so that the shell prints additional information at the prompt

With a few changes, your shell can print the name of the current command number at the prompt. This would initially appear to be a convenience/appearance-only tweak, but it turns out to be very useful both for command history purposes and for keeping track of where you're doing what.

Add the following code to your .cshrc file (or ~/Library/init/tcsh/tcsh.mine):

set cdcmd=''
set cdcmd='echo -n "^[]0;$cwd^G"'

set norm_suf='\!''> '
set root_suf='\!''# '
if ( ($SHELL == /bin/csh) || ($SHELL =~ *tcsh)) then
        alias _normal   'set prompt="$HOST $cwd:t $norm_suf"'
        alias _root     'set prompt="%S$HOST%s $cwd:t $root_suf"'
        if ( `whoami` =~ *root* ) then
            alias prmpt_s _root
        else
            alias prmpt_s _normal
        endif
endif


if ($term == xterm) then
        alias win_s 'eval "$cdcmd"'
        alias cd 'chdir \!*;prmpt_s;win_s'
else
        alias win_s 'echo $cwd'
        alias cd 'chdir \!*;prmpt_s'
endif
prmpt_s;win_s

This code snippet is provided on the Mac OS X Unleashed Web site for your convenience.

Remember to turn back to this code and look at it more carefully after you have read through Chapter 18, "Advanced Unix Shell Use: Configuration and Programming (Shell Scripting)." It's not the most elegant shell script, but it should give you some ideas on how you can configure your environment to adjust itself to varying circumstances automatically.

Turn off coredumps

Unix has a friendly feature that when a program crashes, Unix tries its best to keep a record of what was going on with the system and program at the time of its demise. For a normal user, especially one who isn't a programmer, this isn't a particularly useful feature, so it's usually best to disable it.

Add the following line to /usr/share/init/tcsh/login or, preferably, your home directory .cshrc or ~/Library/init/tcsh/tcsh.mine:

limit coredumpsize 0

If you're ever programming and decide that you need coredumps temporarily, you can issue the command unlimit coredumpsize to turn on coredumps for the duration of the shell.

Automate updating the locate database

The locate feature is a great way to find files on your system. To initialize the locate database, you must first run the command:

/usr/libexec/locate.updatedb

Unfortunately, your system is likely to grow and expand more frequently than you can remember to update the locate database. To automate the process, use the /etc/daily or /etc/weekly scripts to automate the process. Simply add the update line to the end of either of these script files (depending on whether you want daily or weekly updates), and the locate command will automatically be kept informed of the latest files on your system.

Hardwire critical services

Although the Mac OS X interface makes it simple to start and stop services, it also opens up the possibility for users to inadvertently shut down critical services by clicking in the wrong place. To hardwire important services, you can remove their dependency on the /etc/hostconfig file, which is usually checked while the computer is booting.

For example, the script that starts the SSH daemon (/System/Library/StartupItems/SSH/SSH) first checks to see whether SSHSERVER:=-YES- is included in the /etc/hostconfig file before it starts. A user, thinking that he's affecting only his account, could easily shut down SSH service by stopping Remote Access within the Sharing System Preference panel.

To make sure that the service always starts at boot time, remove the enclosing shell script condition. In the case of the SSH script, this consists of these lines:

if [ "${ SSHSERVER:=-NO-} " = "-YES-" ]; then
        <startup script goes here>
fi

Removing the starting if condition, and the ending fi statement will cause the service to start no matter what.

Changes such as this are recommended only for machines that are being used as servers. Even though administrative users can still control the processes, they won't be able to inadvertently alter the boot-up configuration without manually editing the startup files.

Disable Graphical Login

If you operate Mac OS X in a public setting, be sure to use the Login System Preference Panel to force login using username and password. By default, Mac OS X 10.1 will display a login screen with an icon representing each user account. While this is an attractive display, it removes 50% of the protection from the system. Rather than having to guess a username and password, a potential attacker only needs the password. If you only use the operating system within a closed environment, there is no need to take this precaution. Add indexing codes here.

Limit access appropriately

As a final note, we'd like to again stress the necessity to limit access to only those individuals who need it. Although most of the changes listed in this appendix are for any user, the administrator must make the decisions as to who or what has access to the computer. We highly recommend exploring TCP Wrappers, the Mac OS X firewall system, and exploiting configuration files such as /etc/sudoers and /etc/ftpusers.

Keeping track of how your system is being used will be the toughest part of running a Mac OS X multi-user system. As we've repeated throughout the book: "Less is more." The fewer services you run, the better. The less access you give to the outside world, the better. Follow this rule, and you'll have no problem maintaining a secure and stable Mac OS X installation.

Previous Section