AM: ……………………………………………………………………………………….. * 8 * * * * dbadmin /usr/local/bin/db-backup.sh ……………………………………………………………………………………….. In this case, you’d find that the job would run at 8 AM, all right, as well as at 8:01, 8:02, 8:03, and so on, until 9:00 AM. If your job takes more than one minute to run, you’ll quickly bring your system to its knees. The correct way to specify 8 AM and only 8 AM would be to enter this: ……………………………………………………………………………………….. 0 8 * * * * dbadmin /usr/local/bin/db-backup.sh ……………………………………………………………………………………….. To specify ranges of time, such as running this program once an hour, every hour, between 8 AM and 6 PM, Monday through Friday, use something like this: ……………………………………………………………………………………….. 1 8-18 * * * 1-5 dbadmin /usr/local/bin/db-backup.sh ……………………………………………………………………………………….. To specify exact times, separate them with commas: ……………………………………………………………………………………….. 1 8,10,12,15,18 * * * 1-5 dbadmin /usr/local/bin/db-backup.sh ……………………………………………………………………………………….. Or, more interestingly, you can specify fractions of time, or steps. For example, to run a program every five minutes, enter the following: ……………………………………………………………………………………….. */5 * * * * * dbadmin /usr/local/bin/db-backup.sh ……………………………………………………………………………………….. You can also combine ranges with steps. For example, if you want your job to run every five minutes, but want it offset by one minute from the preceding job, you could use this: ……………………………………………………………………………………….. 1-56/5 * * * * * dbadmin /usr/local/bin/db-backup.sh ……………………………………………………………………………………….. You can control the day a job runs with two fields: the day of the month and the day of the week. If you specify both a day of the month and a day of the week, the job will run whenever either condition is met. For example, you might tell cron to “Run this job on the 1st and the 15th, plus every Monday” as follows: ……………………………………………………………………………………….. 55 13 * 1,15 * 1 dbadmin /usr/local/bin/db-backup.sh ……………………………………………………………………………………….. If you find that a job requires a nonstandard environment, set the environment on the command line just as you would in the shell. For example, if your db-backup.sh program requires a 190
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
LD_LIBRARY_PATH environment variable, you can set it like so: ……………………………………………………………………………………….. 55 * * * * * dbadmin LD_LIBRARY_PATH=/usr/local/dblib ;/usr/local/bin/db-backup.sh ……………………………………………………………………………………….. /etc/csh.* The /etc/csh.* files contain systemwide defaults for csh and tcsh. When a user logs in with either of these shells, the shell executes any commands it finds in /etc/csh.login. Similarly, when the user logs out, /etc/csh.logout is executed. You can place general shell configuration information in /etc/csh.cshrc. /etc/dhclient.conf Many operating systems give you very basic DHCP client configuration with no opportunity to fine-tune or customize it; you either use it or you don’t. Any operating system that uses the Internet Software Consortium’s DHCP client, including all of the BSDs, lets you fine-tune your DHCP client setup. In most cases, an empty DHCP client file (/etc/dhclient.conf) will give you full DHCP functionality, but won’t work correctly in all situations. Perhaps you’re connecting to a DHCP server across the country, your local LAN is having problems, or you have multiple DHCP servers. You may be able to solve these problems by tweaking your DHCP configuration. A DHCP lease contains your network configuration information, such as the IP address you get, the default route, and the nameservers available for your use. Without a valid, correct lease, you won’t have Internet connectivity. Entries in dhclient.conf resemble C code and generally include a variable declaration, followed by a value. Each line ends in a semicolon. Prolonging Lease Requests When dhclient starts, it requests the last IP address it used (leased) and, by default, spends ten seconds trying to get that address. The reboot time is the length of time the client will spend trying to get the old address re-issued. To change this waiting time, use the reboot statement. For example, I’ve been on large corporate networks where the DHCP server was in another state; by adjusting the reboot time upwards, I could easily get my previous network address. Just specify the reboot time in dhclient.conf, with a trailing semicolon in standard C code style. ……………………………………………………………………………………….. reboot 20; ……………………………………………………………………………………….. If the client cannot get its previous IP address in the reboot time, it will request a new one instead. 191
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
Here are some typical environment variables as set in /etc/crontab on a FreeBSD 4.5-STABLE system. ……………………………………………………………………………………….. # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/ # ……………………………………………………………………………………….. The hash marks are comments or empty lines used to separate entries and make the file somewhat easier to read. Beneath the environment information, the crontab file is divided into eight columns, forming a table. The first six columns represent the time the command should run: minute, hour, day of the month, month of the year, and day of the week, in that order. An asterisk (*) in any column means “every one,” while a number means “at this exact time.” Following the time columns is the username the job runs as, then the command. User crontab files are almost identical, lacking only the username column. Specifying Times You must use a valid number for times in crontab. The rule is that minutes, hours, and days of the week start with 0, and days of the month and months begin with 1. Also, thanks to an ancient disagreement between AT&T and BSD, the day of the week uses both 7 and 0 for Sunday. For example, to have user dbadmin run the program /usr/local/bin/db backup.sh at 55 minutes after each hour, every day to infinity, your crontab line would look like this: ……………………………………………………………………………………….. 55 * * * * * dbadmin /usr/local/bin/db-backup.sh ……………………………………………………………………………………….. Asterisks tell cron to run this job every hour, every day of the month, every month, and every weekday. To run this job only at 1:55 PM each day, you would use the following: ……………………………………………………………………………………….. 55 13 * * * * dbadmin /usr/local/bin/db-backup.sh ……………………………………………………………………………………….. Here, 13 represents 1:00 PM on the 24-hour clock, and 55 the number of minutes past the hour. One common mistake people make when using cron is to specify a large unit of time, but miss the small one. For example, suppose you entered the following, intending to run a job every day at 8 189
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
Dotdir The dotdir entry contains the path for sample user dotfiles, such as .cshrc, .login, and so on. The default directory contains reasonable defaults. If you want to create custom dotfiles for your system, it’s best to make your own directory under /usr/local/share/skel so that system upgrades won’t overwrite your changes (see Chapter 6). Send_message If you put a full path to a file in send_message, adduser sends each new user a welcome message. If you set this to no, no message will be sent. The adduser message uses variables; you can add your own by editing /usr/sbin/adduser. If you’re familiar with Perl, this isn’t difficult; if not, you’re better off just using the variables offered: $username, $fullname, and $password. (Since this message is mailed to the new user, including the password is somewhat useless in addition to foolish. Too, the user has presumably used his password to retrieve this message, so he should have it.) Go ahead and create your own message instead of using the brief and generic default if you wish. I generally use an /etc/adduser.message somewhat like this, substituting the appropriate company name as needed: ……………………………………………………………………………………….. $fullname, Welcome to The Company. Help is available at 800-555-1212, or online at http://helpdesk.companyname.com. Use of this account is governed by our acceptable use policy, available at http://aup.companyname.com or on this system in /usr/local/share/company/aup. Thank you for your business. We look forward to serving you. The Company Support Staff. ……………………………………………………………………………………….. Logfile The logfile setting tells adduser where to write a log of everything it does. The default works. Home If your system has unusual partitioning, you might want user directories in a different place than the usual /home. You can control this with the home setting. Path If you install software in an unusual location, you might need to change the path entry. (Some systems have their additional programs stored in /opt.) 187
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Shellpref The shellpref setting stores the list of available shells, in order of preference. If you add or remove a shell, you need to correct this. Defaultshell The defaultshell setting contains, as you might guess, the default user shell. Defaultgroup The defaultgroup entry is a little different. FreeBSD assigns a unique group to each user. For example, when you add the user mwlucas, it tries to create a group mwlucas (which allows greater flexibility when assigning permissions). To have every user be a member of a particular group, put the name of the group here; otherwise, leave this set to USER. Defaultclass The defaultclass line controls what login.conf (see /etc/login.conf) class that adduser assigns by default. You can leave this empty, or assign a class from those you have previously configured in /etc/login.conf. Uid_start Finally, the uid_start variable determines the user ID (UID) number that adduser will begin with; the default is 1000. You might want to change this number to match UIDs across multiple operating systems; various Linux distributions start with different UID numbers, for example. But if UID synchronization isn’t important to you, don’t worry about this setting. /etc/crontab The crontab file controls the FreeBSD job scheduler, cron, which allows the administrator to have the system run a command at any time. Each user has a separate crontab file, which can be edited with crontab -e. The /etc/crontab file is the system’s file. Unlike user crontabs, /etc/crontab lets the sysadmin specify which user will run a job. For example, the sysadmin can basically say, “Run this job at 10 PM Tuesdays as root, and run this other job at 7 AM every day as nobody.” Other users can only run jobs as themselves. Note The /etc/crontab file is considered a FreeBSD system file. Be careful not to overwrite this file when you upgrade (see Chapter 6). One way to simplify upgrading /etc/crontab is to set your custom entries at the end of the file, marked off with a few lines of hash marks (#). Environment Statements The /etc/crontab file begins with some environment statements because cron needs to set up a shell environment for the programs it starts. If you’re familiar with shell programming, you can alter these statements to fit your system, but be careful when making blanket changes because changes made at the top of /etc/crontab affect all programs run from the crontab. (You can specify environment variables on the command line for each command you run from cron.) 188
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
/etc/defaults/rc.conf One commonly used file is /etc/defaults/rc.conf. It contains dozens of lines like this: ……………………………………………………………………………………….. named_enable=NO” ……………………………………………………………………………………….. To change this setting, edit /etc/rc.conf, not /etc/defaults/rc.conf. When editing /etc/rc.conf, list the variable you want to change and what you want to set it to. Your /etc/rc.conf entry will then override what’s in /etc/defaults/rc.conf. (Do not just copy the default file to /etc! This causes any number of problems.) Note While the system install process creates /etc/rc.conf, it’s normal to find that you need to create other override files in /etc. Once you understand the various default files, you can easily assess an unfamiliar FreeBSD system simply by checking the corresponding override files in /etc. /etc/adduser.conf Creating new users on some UNIX systems is a pain, requiring you to manually edit /etc/passwd, rebuild the password database, edit /etc/group, create a home directory, install the various dotfiles, and so on. FreeBSD’s adduser(8) program makes it much simpler to add users by running all these other programs for you. The adduser.conf file holds adduser’s default settings. These variables are easily set just by putting the name, an equal sign, and the value. You can add comments just by putting a pound sign in front of them. Here’s a sample entry from this file, with its related comment: ……………………………………………………………………………………….. # verbose = [0-2] verbose = 1 ……………………………………………………………………………………….. Verbose The first entry, verbose, controls how much you see when running adduser. With verbose = 0, adduser prompts you for the new user information and nothing else. If you set verbose = 1, adduser lets you rewrite /etc/adduser.conf before adding a new user. If you set verbose = 2, adduser gives you a great many warnings, questions, and other information. (While the default is 1, you can easily set this to 0 once you’re familiar with the process, and have adduser.conf set up the way you like it.) Defaultpasswd The defaultpasswd entry, either yes or no, controls whether users have a password set by default. If you have a passwordless account on your system, anyone who knows the username can connect to your system. In any circumstance where you have even the mildest concern for security, set this to yes. 186
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Perhaps it’s something innocent, but it might be an intruder’s backdoor. Unexplained system problems are a hint as well. Many intruders are ham-fingered klutzes with few sysadmin skills; they use click-and-drool attacks and think that they’re tough. (Truly skilled intruders can not only clean up after themselves, but also ensure that the system has no problems so that you won’t be alerted.) Unexplained reboots might be a sign of a new kernel being installed. They might also be a sign of failing hardware or bad configuration, so they should be investigated anyway. There are two security tools I particularly recommend for becoming familiar with your system. The first is lsof(8) (/usr/ports/sysutils/lsof), which lists all open files on your computer. Reading this is an education in and of itself; you probably had no idea that your Web server opened so much crud. Seeing strange files open indicates that you’re either not familiar with your system or someone’s doing something you probably don’t want her to do. The second tool is nessus(8) (/usr/ports/security/nessus). It’s an automated vulnerability scanner. Running security audits on your own machines is an excellent way to see what an attacker might see on your systems. If You’re Hacked There’s no easy answer for what to do if your system is hacked. Huge books are written on the subject. Here are some general suggestions, however. First of all, a hacked system cannot be trusted. If someone has gained root access on your Internet server, she could have replaced any program on the system. Even if you close the hole she got in through, she could have installed a hacked version of login that sends your username and password to an IRC channel somewhere. Don’t trust your system. An upgrade will not cleanse your system, as even sysinstall and the compiler are suspect. Feel free to write FreeBSD-security@FreeBSD.org for some advice. Describe what you’re seeing, and why you think you’re hacked. Be prepared for the final answer, though: reinstall your operating system from known secure media (FTP or CD-ROM), and restore your data from backup. (You did read Chapter 3, right?) A good security process will increase your chances of never being hacked. Good luck. 184
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Chapter 9: Too Much Information About /etc Overview The /etc directory holds the basic configuration information needed to boot a UNIX system. Every time I encounter an unfamiliar UNIX, one of the first things I do is scope out /etc. The fastest way to go from a junior UNIX admin to a mid-grade one is to read /etc. Yes, all of it. Yes, this is a lot of reading. But understanding /etc means that you understand how the system hangs together. As you progress as a UNIX admin you’re going to pick up this information piecemeal anyway, so you might as well make it easy on yourself and assemble this portion of your toolkit at the beginning. Many /etc files are discussed in a chapter where they’re most relevant (such as /etc/services in Chapter 5. This chapter will cover the important files that don’t quite fit anywhere else. Varieties of /etc Files Different UNIX systems use different /etc files. In many cases, these files are simply renamed or restructured files from BSD4.3 or BSD4.4. The first time I encountered an IBM AIX box, for example, I went looking for a BSD-style /etc/fstab. It wasn’t there. But a little hunting led me to /etc/filesystems, which turned out to be an IBM-specific rearranged version of /etc/fstab. Knowing that the information existed somewhere in /etc, and knowing what files it obviously wasn’t in, made the search quite short. Even radically different FreeBSD systems have almost identical /etc directories. While some add-on programs insert their own files here, you can expect certain files to be on every FreeBSD system you encounter. Note Before you touch any /etc files, review the information on RCS (Revision Control System) in Chapter 3. I strongly recommend that you create an /etc/RCS directory and use it religiously when experimenting. Changes in /etc can completely disable your system. While recovering a system’s scrambled filesystem table can help turn a competent administrator into a good one, it’s one of the least pleasant ways to get there. Default Files The files in FreeBSD’s /etc/defaults/ directory each contain variable assignments. These files are not intended to be edited by the administrator; instead, they’re designed to be overridden by a file of the same name directly under /etc. For example, the upgrade process completely replaces the files in /etc/defaults. While every new version of FreeBSD has a slightly different default configuration, the developers go to great lengths to ensure that changes to these files are backward-compatible. This means that you won’t have to go through the upgraded configuration and manually merge in your changes; at most you’ll have to check out the new defaults file for nifty new configuration opportunities. 185
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
through the various files.) To determine which jail a process is part of, first find the directory for the process ID you’re interested in, and then look for a file named status. The last word in the status file is the host-name of the jail the process is running in. If the process is not jailed, the last word is a hyphen (-). Shutting Down a Jail When you shut down the host server, the various client jails are shut down as well. Shutting down a jail without shutting down the host is only slightly more complicated. Programs such as shutdown(8) and reboot(8) are useless for shutting down a jail because their main responsibility is to sync and unmount disks, disconnect the network, and so on. A virtual machine does not have those responsibilities. To shut down a jail, first log in to the jail as root. If your jail is hosting programs that like a nice, safe shutdown, such as databases, you should run the shutdown script to shut them down. ………………………………………………………………………………………. # /bin/sh /usr/local/etc/rc.d/programname.sh stop # /bin/sh /etc/rc.shutdown ………………………………………………………………………………………. Once that’s done, send the jail’s main process (-1) a shutdown signal, also known as signal 15. ………………………………………………………………………………………. # kill -15 -1 ………………………………………………………………………………………. This will shut down all jail processes. Since a jail is only processes, the jail will be shut down at this time. Note Do not do kill -15 -1 on a nonjailed server. You’ll shut down lots of stuff, leaving your system in a fairly useless state similar to single-user mode. Monitoring System Security So, you think your server is secure. Maybe it is, for now. Unfortunately, there’s a class of intruder with nothing better to do than to keep up on the latest security holes and try them out on systems they think might be vulnerable. Even if you read FreeBSD-security religiously and apply every single patch that comes along, you might still get hacked some day. While there is no way to be absolutely sure that you haven’t been hacked, the following hints will help you be aware when something does happen: Be familiar with your servers. Run ps -axx on them regularly, and learn what processes normally run on them. If you see a process you don’t recognize, investigate. Take a look at your open network ports via netstat -na and sockstat. What TCP and UDP ports should your server be listening on? If you don’t recognize a port, investigate. 183
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
………………………………………………………………………………………. # mount -t procfs proc /jail1/proc ………………………………………………………………………………………. Your jail is now ready. Entering the Jail Once you have everything configured, use jail(8) to start a jail: ………………………………………………………………………………………. # jail
………………………………………………………………………………………. For example, to do basic configuration of our test jail, do this: ………………………………………………………………………………………. # jail /jail1 jailhost 192.168.1.223 /bin/tcsh ………………………………………………………………………………………. You’ll see a shell prompt, at which point you’re in single-user mode in your jail and your jail is up and running. You could choose any shell you like in the default install I like tcsh for interactive use, so that’s my example. There are differences between your current state and FreeBSD single-user mode, however. While the jail’s startup sequence has not been run, the network is configured by jail. Some commands are unavailable in a jail. For example, try to add an alias to your network interface, and you’ll get a “permission denied” error. Play around a little, and try to break out of the jail. Try to go to a directory you know exists on the system, but is outside of your jail directory. You’re root; try to access processes you know are running on the system. When you’re tired of beating your head against that brick wall, explore the jailed system. Powerful UNIX tools like perl(1) and cc(1) are fully available. You could even cvsup in a jail and rebuild world, although this is not a good idea. (Remember, your kernel and userland absolutely must be in sync; a jailed userland will not crash the kernel, but it certainly won’t work as expected!) Processes Processes in the jail cannot see the rest of the system. Our host server is running a jail, among many other things. Here’s a top snapshot from within a jail running in single-user mode. You can see that the shell process is running, and the top process, but nothing else. You cannot see the processes from the main system. ………………………………………………………………………………………. last pid: 10578; load averages: 0.00, 0.00, 0.00 up 1+09:21:29 19:16:49 2 processes: 1 running, 1 sleeping CPU states: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle Mem: 6708K Active, 27M Inact, 23M Wired, 36K Cache, 61M Buf, 444M Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 10574 root 20 0 1432K 1116K pause 0 0:00 0.00% 0.00% tcsh 10578 root 96 0 1956K 1136K CPU1 1 0:00 0.00% 0.00% top 180
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services