Unix Class Foundations 5
From Rivalug Wiki
Based on: http://www.geekcomix.com/classnotes/ by Samuel Hart (hart@physics.arizona.edu) in 2005 released under Creative Commons Attribution, Share Alike Generic License 2.0
Sometimes the original site disappears, but is still available on the Wayback Machine:
http://web.archive.org/web/20080621235004/http://www.geekcomix.com/classnotes/
The following material is also released under Creative Commons Attribution, Share Alike Generic License 3.0
Lowlevel System Control
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Lowlevel_System_Control
We have seen before (see Unix_Class_Foundations_4#inittab_and_Boot_Scripts ) that the Linux system has a series of "runlevels" which it switches into at different stages during its boot/shutdown and normal operation cycles.
We have also seen that at a very high-level, Linux can be switched between runlevels by clicking various "Shutdown" or "Reboot" buttons at the graphical user interface. But how do we control these run-levels if we are only operating from the command-line?
telinit
Recall that init is the master of all processes. Your system is essentially "spawned" from init. Also recall that we briefly mentionned the command telinit as a means for switching between runlevels.
telinit is actually just a special link to the init program. It takes a character, and then calls init, instructing it to perform some function based upon that character.
The telinit command has the following usage (as specified from it's man page):
telinit [ -t sec ] [ 0123456sSQqabcUu ]
Where:
0,1,2,3,4,5 or 6
tell init to switch to the specified run level.
a,b,c
tell init to process only those /etc/inittab file entries having runlevel a,b or c.
Q or q
tell init to re-examine the /etc/inittab file.
S or s
tell init to switch to single user mode.
U or u
tell init to re-execute itself (preserving the state). No re-examining of /etc/inittab file happens. Run level should be one of Ss12345, otherwise request would be silently ignored.
When init switches runlevels, it must first stop all of the processes which will not be active in the next runlevel (recall that some runlevels do not have networking, naturally all networking subsystems should be stopped... additionally, if switching to runlevel 6, we are rebooting, so all processes must be stopped). init does this by first sending the SIGTERM signal. After a certain duration, if the process has not yet quit, init will send a SIGKILL signal to it.
You can adjust the duration of time init waits for processes to terminate with the "-t sec" option. You specify the number of seconds to wait between the SIGTERM and SIGKILL signals. This number usually defaults to 5 seconds on most UNIX systems.
While you can technically use the telinit command to shutdown or reboot a Linux machine, thats not what it usually used for. The most common uses for the telinit command are to switch to single user mode (e.g., during some sort of network attack) or cause init to reread inittab without rebooting.
In case you haven't already figured it out, Linux (and most UNIXes) very rarely require reboots. As we have seen, you can drastically redefine the system's init parameters, and cause the system to reload its inittab file to enact those changes without ever having to take the system offline. Just about the only time you really have to reboot is when you update your kernel.
shutdown
The classic UNIX command for bringing a system down (or rebooting) is the shutdown command. Most GUI tools for shutting the system down will actually be calling shutdown behind the scenes.
Shutdown takes several parameters at the command line, and then usually instructs init to switch runlevels. Shutdown is a better option for reboots/shutdowns than telinit because it does it's job in a more secure way: It sends warning messages to all logged in users, blocks all incoming logins, and sends warning signals to all processes (thus giving them a chance to exit cleanly). Because of it's benefits over just plain telinit, you should really only think of telinit as a "last-resort" for bringing your system down.
Shutdown has the following usage:
/sbin/shutdown [-t sec] [-arkhncfF] time [warning-message]
Where:
-a
Use /etc/shutdown.allow. If the file exists, it compares the login names in that file with the list of people that are logged in in a virtual console. Only if one of those authorized users or root is logged in, it will proceed.
-t sec
Tell init to wait sec seconds between sending processes the warning and the kill signal, before changing to another runlevel.
-k
Don't really shutdown; only send the warning messages to everybody.
-r
Reboot after shutdown.
-h
Halt after shutdown.
-n
DEPRECATED! Don't call init to do the shutdown but do it ourself. The use of this option is discouraged, and its results are not always what you'd expect.
-f
Skip fsck on reboot.
-F
Force fsck on reboot.
-c
Cancel an already running shutdown. With this option it is of course not possible to give the time argument, but you can enter a explanatory message on the command line that will be sent to all users.
time
When to shutdown (we'll look at the format shortly).
warning-message
Message to send to all users.
The time argument can have different formats. First, it can be an absolute time in the format hh:mm, in which hh is the hour (1 or 2 digits) and mm is the minute of the hour (in two digits). Second, it can be in the format +m, in which m is the number of minutes to wait. The word now is an alias for +0.
So, for example, what would the following shutdown commands do?
1) shutdown -h now 2) shutdown -rf +30 "Sorry folks, gotta reboot" 3) shutdown -k now "INTRUDER ALERT" 4) shutdown -c "Whoops, I'm no 1337 4aXor..." 5) shutdown -rF 00:00 "Daily FS check."
halt, reboot
On many UNIX systems, there exist additional programs which, in turn, supply and even more simplified interface to shutdown. These programs are known generally as halt and reboot.
Often, these two map almost literally to:
halt == shutdown -h now reboot == shutdown -r now
but do not assume this will always be the case regardless of UNIX.
halt and reboot take the following options:
halt [-n] [-w] [-d] [-f] [-i] [-p] reboot [-n] [-w] [-d] [-f] [-i]
Where:
-n
Don't sync before reboot or halt.
-w
Don't actually reboot or halt but only write the wtmp record (in the /var/log/wtmp file).
-d
Don't write the wtmp record. The -n flag implies -d.
-f
Force halt or reboot, don't call shutdown (on some systems, this is akin to telinit'ing into the associated runlevel).
-i
Shut down all network interfaces just before halt or reboot.
-p
When halting the system, do a poweroff. This is the default when halt is called as poweroff. This may be useful on equipment which has buggy BIOSes that do not translate ACPI requests correctly.
Terminal Fundamentals
init-getty-login-shell
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Init-Getty-Login-Shell
Last time we looked at init. We learned that init was the master process from which all processes were spawned. Just this morning, we looked at programs to control init.
However, there is a very important step missing between when init runs and when you can actually start using your UNIX box.
GETTY
Recall that
"TTY" comes from the industry-wide abbreviation for "Teletype" since original Unix computers used these devices for input and output.
A TTY today is simply some sort of I/O device for interfacing with your UNIX box (this is a bit of an over-exaggeration... but for the purposes of this class, it's okay).
GETTY is a program that is invoked by init. It is the second process in series that ultimately connects a user with the UNIX system. Usually getty outputs the contents of /etc/issue (which can contain introductory messages about the system) and then starts login sessions for the user to connect. These login sessions will then spawn the shell whenever a user connects. This procedure is generally refered to as init-getty-login-shell and has been a common mantra throughout UNIX history. If there is ever a problem connecting to a UNIX system as a user, then one of these four elements is to blame.
getty is spawned by init based upon entries inside the /etc/inittab file (which is to be expected). When it is invoked, it is generally given a baud rate (connection speed) and a device name to use (one of /dev/tty1, /dev/tty2, etc.). For example, the following is a possible entry from /etc/inittab
# /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # <id>:<runlevels>:<action>:<process> 1:12345:respawn:/sbin/getty 38400 tty1 2:2345:respawn:/sbin/getty 38400 tty2 3:2345:respawn:/sbin/getty 38400 tty3 4:2345:respawn:/sbin/getty 38400 tty4 5:2345:respawn:/sbin/getty 38400 tty5 6:2345:respawn:/sbin/getty 38400 tty6
Note that here, the first field of inittab, the "id", must be the same as the device specification. Or "1" must correlate to "tty1" and so on. Also note that the first invocation (id "1") runs at all non-halt/reboot modes including "single user", whereas the others do not. This is because, when booting into single user mode for maintenance, you will need one and only one terminal.
mingetty
mingetty is an alternative to getty which is most often employed on Red Hat and Red Hat-based systems. It's only real difference is that it is not suitable for other, more arbitrary, terminal connections (such as serial line connections.) It's format inside of inittab is not much different than getty. It simply lacks the baud rate:
# Run gettys in standard runlevels 1:12345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6
Extra options for getty
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Extra_Options_For_Getty
Though the common defaults detailed in the previous section should be completely valid for most purposes, there are a few options for getty worth mentionning in case the need ever arises to use them. Many of these are particularily important if you are a UNIX administrator where dial-up is offered (such as an ISP or an automated TTD system).
getty options
-h
Enable hardware flow control. This is especially usefull if getty is acting over a modem connection (as an ISP would have), or some other device which offers hardware flow control (RTS/CTS).
-i
Do not display the contents of /etc/issue (or other) before writing the login prompt. Terminals or communications hardware may become confused when receiving lots of text at the wrong baud rate; dial-up scripts may fail if the login prompt is preceded by too much text.
-l login_program
Invoke the specified login_program instead of /bin/login. This allows the use of a non-standard login program (for example, one that asks for a dial-up password or that uses a different password file).
-n
Do not prompt the user for a login name. This can be used in connection with -l option to invoke a non-standard login process such as a BBS or automated TTD system. Note that with the -n option, getty gets no input from user who logs in and therefore won't be able to figure out parity, character size, and newline processing of the connection. It defaults to space parity, 7 bit characters, and ASCII CR (13) end-of-line character. Beware that the program that getty starts (usually /bin/login) is run as root.
-t timeout
Terminate if no user name could be read within timeout seconds. This option should probably not be used with hard-wired lines.
Switching between Virtual Consoles
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Switching_Between_Virtual_Consoles
Let's look back at our standard entries for getty in inittab (mingetty for Red Hat is practically identical):
1:12345:respawn:/sbin/getty 38400 tty1 2:2345:respawn:/sbin/getty 38400 tty2 3:2345:respawn:/sbin/getty 38400 tty3 4:2345:respawn:/sbin/getty 38400 tty4 5:2345:respawn:/sbin/getty 38400 tty5 6:2345:respawn:/sbin/getty 38400 tty6
As you can see, for all of the multi-user modes a getty session begins. This means we have 6 login sessions sitting there waiting for us to connect to. But where are these sessions and how do we access them?
Virtual Consoles
Each of these sessions spawn in what are called "Virtual Consoles". You can switch to each of these virtual consoles and login. As Linux is multi-user, you can be logged in to as many of them as you desire, and be running programs in each. You can additionally switch between them whenever needed.
Additionally, if you are running an X server on your system, there will be an extra seventh virtual console for that. If graphical mode under X is the default means for logging into your computer, then this seventh virtual console will be the default one on your screen. In other words, you will typically have the following virtual console definations on most Linuxes:
1 : Text console 2 : Text console 3 : Text console 4 : Text console 5 : Text console 6 : Text console 7 : X (GUI) console
You can switch between these virtual consoles by holding down "Ctrl+Alt" and then pressing one of the function keys, F1-F7. So "Ctrl+Alt+F1" will switch to the first virtual console, "Ctrl+Alt+F7" will switch back to your XFree86 console. If you are not running your system with XFree86 (it is headless, or some server which you do not want to waste resources on), then the seventh console may not exist (it may also just be another text console, depending upon how it is set up).
NOTE: This is the default way to switch consoles in most Linuxes and many other UNIXes, though it is by no means universal. On some UNIXes, there are other "META-keys" which perform the same functions as "Ctrl", "Alt", and the function keys do here.
Why would you need something like this? There are many reasons, which will become evident as we proceed through the future courses. But, briefly some reasons are:
- X has locked up: Although Linux itself is not likely to freeze or lockup, XFree86 running on top of it might. It could be that the graphic card has buggy support, or that some X application has run-away or gone zombie and ground X to a halt. By switching to a text console, you will still be able to log in and kill whatever process is causing the problems.
- Securely working as root: We have mentionned that running X as the administrator is a dangerous practice (though we'll see why this is in UNIX03). Logging in as root via a text console can be much more secure than logging in as root under X (however, there are dangers even there! Again, we'll examine these in UNIX03).
- Quick logons: Logging into X can be quite slow (especially if you are using a desktop environment such as Gnome or KDE). If all you are doing is checking something that can be checked from the command-line (as everything under UNIX can be) then it's much quicker to just log into a text console instead of X.
- Switching runlevels: If you are rebooting, halting, or simply switching runlevels, chances are your X server will have to be killed. By switching runlevels from a text console, you wont be kicked or booted during the init change (meaning any X applications wont be rudely killed during the switch. Big integrated DEs like GNOME or KDE aren't very graceful when they are told to terminate. Killing them may result in a desktop environment that must be reset in order to be used again.)
7 Virtual Terminals not Universal
One final thing we should mention about this is that it is not universally defined that all UNIX or Linux distributions must offer 7 virtual consoles. There are many different UNIXes and Linuxes which define things quite differently.
If in doubt, consult your distribution's documentation and possibly the /etc/inittab file.
Scheduling Under Linux
Overview of UNIX Scheduling
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Overview_Of_UNIX_Scheduling
UNIX offers a very robust system by which programs and commands can be scheduled. The two main components of this system are the at suite of utilities and the cron system.
As with everything else, scheduled events must be run as a given user. The at suite is a scheduling system which will only run as the user which starts it. Cron, on the other hand, can be invoked both as individual users and system-wide.
Run at
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Run_At
The at suite is a must less featureful sheduling system than cron. Thus, it is generally easier to use, but will only perform a subset of what cron can do.
The basic usage of at is to specify a sequence of commands (or a shell script) which are then run at a later time (by invoking /bin/sh). It is usaully for quickly setting up a "one-time" event, and not for reoccuring events.
The basic at suite is as follows:
at [options] [-f file] TIME atq [-q queue] atrm job [job...]
at accepts times of the form HH:MM to run a job at a specific time of day. (If that time is already past, the next day is assumed.) You may also specify midnight, noon, or teatime (4pm) and you can have a time-of-day suffixed with AM or PM for running in the morning or the evening. You can also say what day the job will be run, by giving a date in the form month-name day with an optional year, or giving a date of the form MMDDYY or MM/DD/YY or DD.MM.YY. The specification of a date must follow the specification of the time of day. You can also give times like now + count time-units, where the time-units can be minutes, hours, days, or weeks and you can tell at to run the job today by suffixing the time with today and to run the job tomorrow by suffixing the time with "tomorrow".
For example, to run a job at 4pm three days from now, you would do
at 4pm + 3 days
To run a job at 10:00am on July 31, you would do
at 10am Jul 31
and to run a job at 1am tomorrow, you would do
at 1am tomorrow
If called without the "-f" option, at reads in commands from STDIN (the command line or a pipe) until an EOF or termination character is reached. In this way, you can use it as a simple means to capture keystrokes to be ran later.
If you, instead, have a shell script which contains a sequence of commands, you can have at use that script by specifying it with the "-f" option. For example, if I had the script "mirror_website.sh", and I wanted it to run at midnight on August 24th, my at command would be
$ at -f mirror_website.sh midnight Aug 24
To list the current jobs in your queue, you use the "atq" command.
sam@rygel:~/work/programs/temp$ atq 1 2003-08-31 00:00 a sam 2 2003-08-11 16:00 a sam
You can also remove any scheduled job using the "atrm" command. You can specify as many jobs to remove as you want, all specified by their job numbers. For example, if I wanted to remove the second job from my above queue, I would execut
sam@rygel:~/work/programs/temp$ atrm 2
sam@rygel:~/work/programs/temp$ atq 1 2003-08-31 00:00 a sam
PROJECT : Schedule a one time event
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Schedule_A_One_Time_Event
Using at which we have just discussed, schedule a non-recurrant event where the "treereset.sh" script which we wrote back in /Create A Simple Shell Script runs at the following times:
- In five minutes from now
- In fifteen minutes from now
- Tomorrow at noon
- September 20th, at 8:00am.
Cron-Introduction
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Cron-Introduction
at is a simple program which, when ran, initiates a scheduler for events. Cron, on the other hand, is a daemon which is started during the init process and is always running. It reads schedules of events for system-wide events and individual user events and performs them at recurring intervals. Whereas at is ideal for quick, one-time events, cron is much more suited for things which must happen on a regular basis.
Overview of the cron daemon
The cron daemon is where all timed events are initiated. It is executed upon system initialization and remains active while the system is operating in multi-user mode. Cron wakes up every minute and examines all the stored configuration files, called crontabs, to check each them for commands that may be scheduled to be executed at the current time. Some systems have limits to the number of tasks that can be scheduled during the one minute time period. Most notably, because of the low number, is SGI's IRIX 5.3 which has a limit of 25 jobs.
Besides starting commands each minute, some cron daemons also check to see if its spool directory's last modified time has been updated. If it has, cron will check the modification time on all crontabs and reread the ones that have been modified. Other cron daemons examine new crontab files when first initialized and when the commands crontab or at are executed. This reduces the overhead of checking for new or changed files at regularly scheduled intervals.
Cron searches the crontab spool directory for crontab files. These files are named after user accounts. For instance, if the system administrator is logged into the root accounts creates a crontab file, it will be named root and will be placed in the crontab spool directory. If Bill Wilson, whose username is bill, creates a crontab file it is named bill in the crontab spool directory. When executing commands, any output is mailed to the owner of the crontab (or to the user named in the MAILTO environment variable in the crontab, if such exists).
The configuration files used to control the operation of cron are called crontab files or cron tables. These files contain information about the time, date and command to execute. Different versions of UNIX store cron and support files in different locations and may use a slightly different format. Since we are focusing on Linux in this class, the following will be very Linux-centric. As always, consult the man pages for your UNIX if unsure.
NOTE: There are actually many different cron daemons to choose from, and there are vocal supporters for each. In fact, cron daemon discussions usually result in "flame wars" when seasoned UNIX administrators debate the merits of their favorite cron implimentation. In this class, we will almost exclusively be focusing on Vixie Cron and Anacron, because they are the most common default choices in distrubutions.
User Specific Cronjobs
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/User_Specific_Cronjobs
The cron table, crontab, file format
Cron table files, or crontabs, are text files which direct the cron daemon's activity. Each line or entry has six fields which are separated by space characters. The first five fields instruct the cron daemon as to when to execute the command, which is contained in the sixth field.
FIELD VALUE ------------------ minute 00 to 59 hour 00 to 23 (military time) day 1 to 31 month 1 to 12 weekday 0 to 6 (0=Sunday) Note: Linux uses sun, mon...
The first five fields can also use any one of the following formats.
* An asterisk character (*) to match all values. * A single integer that matches that exact value. * A comma separated list of integers, like 1,3,5 to match one of the listed values. * A range of integers separated by a dash, like 4-6, to match the values within the range.
Here are sample entries along with a short explanation of when the operation will be performed.
0 * * * * echo "WAKE UP" 2>&1 /dev/console
This entry sends the string WAKE UP to the device /dev/console at the start of every hour on every day of every month.
0 0 * * * calendar -
This entry runs the command calendar which reminds users of holidays and other events at the start of the hour at the start of the day on every day of the month.
10,20,30,40,50 * * * * /adm/checkdaemon 2>&1 | \
/bin/mail -s "CRON:Check" root
This entry runs the command checkdaemon and mails the output of the command to root. The command is run 10, 20, 30 ,40, and 50 minutes after the hour on every day of every month.
QUESTION: Which of these is the correct definition time for this entry?
15 5 * * 1 find /var/preserve/. -mtime +7 -exec rm -f {} \;
1. At 5:15 of every day 2. At 5:15 on Mondays 3. On the first day of the month at 5:15.
Answer: #2
15 5 * * 1 find /var/preserve/. -mtime +7 -exec rm -f {} \;
minutes:hours:monthday:month:weekday
15 5 * * 1
So on weekday number one of every month and every monthday run the command listed.
If you ever need a refresher on the format of a crontab file, the crontab man page in section 5 does an excellent job explaining it:
$ man 5 crontab
The crontab command
The crontab files are not generated by editing a the crontab file in the crontab spool directory, instead the command crontab is used to edit, list, create or remove a crontab file for a user. The crontab command can be used by all the users on a system to create personal crontab as well as by the root account. Users are not allowed to view, edit or create crontab files for other users.
Additionally, the use of cron can be denied to users. This is done to prevent system unfriendly, or security compromising tasks to be performed. When the crontab command is invoked it examines the files cron.deny and cron.allow in the system's cron directory (under /etc on Linux) to grant or revoke the modification of the crontab spool file. If a username appears in the file cron.allow, the crontab command may be executed. If that file does not exist and the users name does not appear in the cron.deny file then cron can be used. If only an empty cron.deny exists, all users can use cron. If neither of these files exist, then only the root user can use cron.
The crontab command without options reads from standard input, so when executed it takes the information entered at the keyboard as input. This makes it easy to remove the existing crontab without really trying. If the crontab is run without options it should be exited with a "Control C" so that the existing crontab is unmodified. Entering a "Control D" will cause the current users' crontab to be replaced with no information, thereby erasing the existing crontab.
The edit option crontab -e for the crontab command copies or creates the current user's crontab file. crontab will execute whatever your default editor is (defined by the environmental variable EDITOR). After editing is complete, the file is installed as the user's crontab file in the crontab spool directory. Not all UNIX's crontab have an edit option. In this case, a file containing the crontab information can be created and read from by the crontab command.
The list option, crontab -l, displays the contents of the current user's crontab file. Here is an example of my crontab on my work machine:
[hart@einstein hart]$ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (.sams-cron installed on Mon Jul 28 10:17:06 2003) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) # run-parts 01 * * * * fetchmail 15 * * * * fetchmail 30 * * * * fetchmail 45 * * * * fetchmail 01 01 01 * * /home/hart/bin/getsophos
You will note that the output from the "-l" option does produce data that is completely valid for another crontab file, so you can pipe the output into another new or backup file quite easily.
The remove option, crontab -r, empties the contents of the current user's crontab file. Note that, unlike atrm, you cannot specify which crontab entries to remove. This is an "all-or-nothing" command.
The crontab command will accept an account name as the first argument if current user has superuser privileges.
Here is a sample session that adds a crontab entry for the current user, lists the crontab entry and then removes it.
# crontab -e (Create the crontab entry within an editor) 1 * * * * /usr/local/bin/runreport
# crontab -l 1 * * * * /usr/local/bin/runreport # crontab -r
Using the crontab command without options to create the crontab file can be done by creating and editing a file. In this example, allcron.
# vi allcron # crontab allcron
Some administrators and UNIX users prefer to handle their crontab configuration in this way. By doing this, you always have a backup of your crontab file. You can issue a "crontab -r", removing all entries from your crontab file, re-edit your external file to reflect any changes, and then simply re-run that file through crontab.
PROJECT : Schedule a user event
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Schedule_A_User_Event
As the student user, create two scripts which will mirror a website as specified in the "/Mirror A Website" project.
Have the first script mirror the main page of http://www.linux.org/ (only 1 level deep), or any other web-site of your choice. Have the mirror dump into /home/student/mirrors/1/. Call this script "mirror_1deep". Run the script, and verify that it works.
Have the second script mirror the same site as above, but this time go 3 pages deep. Have the second script dump the mirror into /home/student/mirrors/2/. Call this script "mirror_3deep". The second script should be identical to the first, but with the depth level set to 3.
Next, schedule the first script ("mirror_1deep") to run as student using cron at the following times:
- Midnight on Tuesday of every week
- 3am on Saturday of every other week
Finally, schedule the second script ("mirror_3deep") to run as student using cron at the following times:
- 1am on the first Monday of every month
- 4pm on the 21st of every month
System Wide Cronjobs
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/System_Wide_Cronjobs
While you could technically run any system-wide cronjobs from the root user's crontab (afterall, the root user has access to everything on the system), this is a very sloppy way to do things, and is generally frowned upon (the rare exception is in the embedded devices arena, where root's crontab is smaller than the norma system-wide setup).
Instead, cron offers a mechanism by which you can set up system-wide cronjobs to be run at very specific times. This is really where the cron daemon you are using can be vastly different from alternative cron daemons. Again, we will only be focusing on Vixie Cron and Anacron in this class, so be sure to check your documentation before applying what we learn here to an arbitrary UNIX system.
/etc/crontab
By far the simplest way to add a system-wide cronjob is to modify the entries in /etc/crontab. This file has the same format as the other crontab files we have examined thus far. The big differences for this system-wide crontab file is that there is an extra field for a user to run as and that you do not need to call "crontab" to reload the file (cron automatically reloads it whenever it wakes up).
However, looking inside of the /etc/crontab file on many Linux systems will give us something like the following:
# /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file. # This file also has a username field, that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin: \
/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
25 6 * * * root test -e /usr/sbin/anacron || \
run-parts --report /etc/cron.daily
47 6 * * 7 root test -e /usr/sbin/anacron || \
run-parts --report /etc/cron.weekly
52 6 1 * * root test -e /usr/sbin/anacron || \
run-parts --report /etc/cron.monthly
So what is this Anacron thing?
Anacron Overview
Anacron is a periodic command scheduler. It executes commands at intervals specified in days. Unlike cron, it does not assume that the system is running continuously. It can therefore be used to control the execution of daily, weekly and monthly jobs (or anything with a period of n days), on systems that don't run 24 hours a day. When installed and configured properly, Anacron will make sure that the commands are run at the specified intervals as closely as machine-uptime permits.
Every time Anacron is run, it reads a configuration file that specifies the jobs Anacron controls, and their periods in days. If a job wasn't executed in the last n days, where n is the period of that job, Anacron executes it. Anacron then records the date in a special timestamp file that it keeps for each job, so it can know when to run it again. When all the executed commands terminate, Anacron exits.
Why may Anacron be useful?
Most Unix-like systems have daily, weekly and monthly scripts that take care of various "housekeeping chores" such as log-rotation, updating the "locate" and "man" databases, etc. Daily scripts are usually scheduled as cron-jobs to execute around 1-7 AM. Weekly scripts are scheduled to run on Sundays. On machines that are turned off for the night or for the weekend, these scripts rarely get run.
Anacron solves this problem. These jobs can simply be scheduled as Anacron-jobs with periods of 1, 7 and 30 days.
Anacron is especially useful for laptop users and for people who only turn their computer on for a few hours a day.
What is Anacron not?
Anacron is not an attempt to make cron redundant. It cannot be used to schedule commands at intervals smaller than days. It also does not guarantee that the commands will be executed at any specific day or hour.
It isn't a full-time daemon. It has to be executed from boot scripts, from cron-jobs, or explicitly.
Anacron Directories
Anacron generally looks for scripts to run in the following directories:
/etc/cron.daily /etc/cron.weekly /etc/cron.monthly
When it spawns for one of these settings, it runs sequentially through the scripts in these directories. Thus, if you had a script which needed to be run daily, provided the system was on, you could place that script inside the /etc/cron.daily directory and it would run.
Take a look at some of the scripts in these directories now.
PROJECT : Schedule a system event
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Schedule_A_System_Event
Our previous scheduled events are not always guaranteed to run when we desire. The at command which runs the "treereset.sh" shell script is only good for a finite number of recurrances, the mirror scripts from the last project will only run if the system is online when they are supposed to run. We want these scripts to run with more regularity.
We want the "treereset.sh" script to run everyday, because there simply cannot be a time when the permissions for the tree we set up in "/Create A Simple Tree" are incorrect.
We also want the mirror_1deep script to run every week, because this simple 1-level deep mirror must happen or else it's our job.
Finally, we want the mirror_3deep script to run every single month, because we must have a more complete backup of the website that occurs every month.
Using the Anacron directories we have just discussed, set up these three scripts to run as detailed.
Introduction to the RPM System
What is RPM
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/What_Is_RPM
As we have discussed, Linux and most UNIX applications have been traditionally distributed as source code. Building an entire system from source is a significant undertaking and is not for the faint of heart.
Because it was such a significant undertaking, distributions were created to make installing a Linux system that much simpler. Many distributions were entirely community based, however some were created for commercial purposes.
Red Hat and RPM
Red Hat was one of the first distributions. The one thing that set Red Hat apart from many of the other distributions was a very clever little package management system called RPM. RPM originally stood for "Red Hat Package Management", but has since been changed to RPM Package Management (ah, joy, another piece of recursive humor like "Gnu's Not Unix") because it is used by many other distributions.
An application was archived, digitally signed, and any installation/uninstallation scripts were bundled up together into a file known as an "RPM" file. This single RPM file could then be easily distributed and installed with very simple commands.
RPM was special because it was one of the first packaging systems to include dependency trees. A dependency tree is really just a list of files and other RPMs that a given RPM depends upon. For example, crontab (which we just looked at) has an RPM under Red Hat that depends upon the following files and packages:
/bin/bash config(crontabs) = 1.10-5 rpmlib(CompressedFileNames?) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix?) <= 4.0-1
Because the RPM told you what you needed in order to use its application, installing applications instantly became much easier. You simply had to track down the requirements, and install them as well.
RPM very quickly became a defacto standard for many, many different Linux distributions. SuSE, Mandrake, even Caldera (now SCO) have all used it. It has evolved to include many new functions including the ability to arbitrarily define installation paths, selectively install packages based upon requirements, and even include several sublayers of package scripting (pre-install, post-install, etc.)
RPM is even the required package format for a Linux distribution to be LSB compliant (LSB is the "Linux Standards Base", and is a new "standardization" effort to make Linux distributions more "alike". Read more about it here: http://www.linuxbase.org/)
RPM was not actually the first package management system used in Red Hat. Originally, they had something called RPP. Later, there were efforts in two other formats, PMS and PM. RPM was the ultimate successor to all of these, combining many of the best atributes of each.
RPM Strengths and Shortcomings
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/RPM_Strengths_And_Shortcomings
RPM Strengths
When RPM works, it works very well. Ideally, installing an RPM is as simple as downloading one file (the RPM), clicking on it in a GUI browser or executing a simple one-line command to install it, and the package is installed.
If the package needs extra packages installed, tracking down those packages and installing them in the same way can also be done.
RPM's biggest strength is that, when it works, it is actually extremely easy to install/setup a new program. It is also just as trivial to uninstall a program. RPM systems can be even easier to maintain than a Windows system (recall that Windows' Add/Remove? Programs dialog only works if a program registers itself... With RPM, every program is registered and contains detailed information about how to get rid of it.)
Similarily, when RPM works, it supplies a very simple way to update and maintain the programs on your system. Scripts (generally included in distribution CDs) auto-update every RPM on your system. These scripts can work quite well when done correctly. You can take an older Red Hat system (let's say, Red Hat 6.2) and easily upgrade it to the latest one (say, 9.0) using the update CDs. The new system will generally do a very good job of updating your system (though some specific programs may be depreciated and removed, or may get their configurations wiped out... but this is to be expected). It is very rare that an updated RPM-based system ceases to work because of the update.
Another strength is that, from a developer's standpoint, RPM creation is very easy. Making RPMs is by far easier than making packages for other management systems.
RPMs Shortcomings
There are two big problems facing RPM-based systems today.
The first one has to do with the fact that Red Hat and other RPM-based vendors have effectively forked their systems away from eachother to make their RPMs completely incompatible. Thus, whereas several years ago you could take a Mandrake RPM and use it under Red Hat (albeit, with some minor massaging into place), now there is no way. Red Hat even forked the RPM-codebase a couple years back making their RPMs no longer standard (though, I think this has been resolved in recent Red Hat systems).
The second problem is actually the really big one. This problem has an effectionate little term associated with it: Dependency Hell.
Imagine you need to install RPM package "foo". foo has the following dependencies:
bar <= 2.0.14 crunchly <= 1.0.2 smedly <= 0.9.9
So you try to install "bar". Ahh, but bar has the following dependencies:
kringly <= 8.0 bang <= 1.2
So you install "kringly", but it requires:
juniper <= 2.0 killroy <= 1.90
Additionally, all the other packages here have their own set of requirements.
As you can see, very quickly this whole process becomes excruciatingly tedious and difficult. Instead of installing one simple RPM, you are now set to install twenty, thirty, even hundreds of packages. Often times these packages will not even be available for your own distribution, and you will be left with the only options of either a) building your own custom RPM for that packages or b) building the whole thing from source.
Now, this "dependency hell" is really only a problem if you stray from what your distribution supplies for you... However, there are times where you will simply have to stray to satisfy some user need. Imagine if your boss requires you to install an Oracle database, but the only RPMS you can find for your distribution are MySQL? or Postgres. Thus, dependency hell is a very real problem for Linux users and administrators.
If you would like more information on this problem, here is an excellent (albeit, biased) article on the subject: http://www.distrowatch.com/dwres.php?resource=article-rpm
Alternatives to RPM
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Alternatives_To_RPM
Debian's DEBs and APT
APT stands for "Advanced Package Tool", and is really a package dependency layer built on-top of some other packaging system. In the case of Debian, that packaging system consists of files called DEBs.
A DEB is fundimentally no different from an RPM. It is an archive of files consisting some larger program. It usually has install and uninstall scripts, a list of dependencies, and architecture information.
What makes Debian's system different is this APT-layer. APT allows the system to automatically track down dependencies for you. So, if we were to want to install package "foo", which had this tree of dependencies that would be difficult to locate and install by hand, APT would find all the dependencies for us and install them.
Using APT, a Debian-based system can very rapidly and easily be updated and new applications installed. We will look more at Debian and APT in the next two courses.
NOTE: It is important to point out that technically there is no reason an RPM-based system can't use APT on top of it. This just hasn't been done too successfully because of the severe incompatibilities between the various RPM-based distros. That being said, there are distros like PLD which are attempting to change that.
Gentoo's emerge
Emerge is a newish format that has been generating a lot of waves in the community. The idea behind emerge is to give you a simple dependency tracking system similar to APT, but to also give you a powerful source-based automated compile system somewhat similar to FreeBSD's ports (which we look at in UNIX02).
The key benefits to a Gentoo/emerge system is that you can typically have much more cutting edge applications and better hardware optimization and support.
These strengths have made Gentoo the fastest growing distribution in terms of users. Gentoo is even the distro of choice in strange places such as Novell.
Slackware
Slackware uses a very simple package management scheme. They have their system set up around simple tar-balls that can be decompressed/dearchived into the root directory and just "fall" into their proper places.
This limits the ways you can install a package, but means that the package really should just work "right out of the box".
RPM Usage
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/RPM_Usage
Installation of an RPM
RPM installation, updation and removal will have to be done as root. Querying the database does not require you to be root.
A basic installation of an RPM file can be accomplished by
rpm -ivh
e.g - rpm -ivh foo-1.03.rpm
At this point rpm will go out and check whether the files required by foo are installed on the system or not. If some other package needs to be installed then it will inform you of the requirements and exit. If some files from the package have been installed by some other package then you will be notified of that also.
Multiple files can also be specified using wildcards so the following is also legal.
rpm -ivh foo*.rpm
Let's look at the options specified.
-i
Specifies installation as the action to be taken.
-v
Will display additional information while installing.
-h
Prints 50 hash marks (#) as installation progresses.
You can get by with just -i but it is generally a good idea to specify -v and -h too so that you get proper feedback.
Other options that may be given are
--replacepkgs
Sometimes you may need to re-install a package that has been damaged then you need to specify this option. If you try an installation then rpm will say that the package is already installed.
--replacefiles
If you get a package with newer versions of a file and you would like to install it then use this option to replace the files.
--force
Force the installation to go ahead regardless of any errors. Failed dependencies will still stop it though.
--nodeps
Package dependencies are any packages that are required by a certain software. Fetchmail may require sendmail or some other mail server to be present on your system. Sendmail is the package dependency for fetchmail. You might have some other mail server installed, like Postfix, and you want to go ahead and install fetchmail. Adding --nodeps to the command line tells rpm to skip the checkup for any dependency packages and to go ahead and install fetchmail. Note that this can be dangerous, unless you know what you are doing. Another place this option is very useful is when you have packages that require each other. So package A will say that package B should be installed, but package B will want A to be installed first. Just install one of the packages with --nodeps before you go on to install the other one.
RPM can also install over the net. If you happen to know the full url of your rpm file then just enter the following to get and install the package.
rpm -ivh ftp://ftp.linux.tucows.com/pub/RedHat/foo.rpm
If the site requires a valid login and password pair then you can enter that in the url too.
rpm -ivh ftp://yahoo@ftp.linux.tucows.com/put/RedHat/foo.rpm
You will be prompted for the password after which the file will be downloaded and installed.
Updating
Updating your current package installation. If you come across a updated package then upgrading would be the right choice. Syntax is pretty much the same as installation. The default behaviour of this command is that rpm will first check for a older version of the package. If one is found then that package is updated otherwise normal installation is done. This is the recommended command to use because it prevents you from installing multiple versions of the same package.
rpm -Uvh filename.rpm
Un-Installation
An package installed via rpm can be uninstalled by
rpm -e <package_name>
The package name would be the name of the package at installation. For example
# rpm -e gpm
would remove the package named gpm.
Occasionally you might get dependency errors when removing packages that are required by other packages. You may use --nodeps here too tell rpm to ignore such dependency errors and uninstall the package regardless, but again, you must be cautious.
Query
Query allows you to query the RPM database for various information on a particular RPM. Generally a query is given with the -q followed by a query option.
If you want to check out the version of the installed package then simply run a '-q' on the package.
$ rpm -q samba - samba-2.0.6-62
If you have a file which you wish to query and find out what package it belongs to, you can use the "-f" option
# rpm -qf /usr/sbin/smbd -samba-2.0.6-62
You can veiw the information on a particular package on your system using the "-i" option. Here is an example for the crontabs package:
[hart@einstein hart]$ rpm -qi crontabs
Name : crontabs Relocations: (not relocateable)
Version : 1.10 Vendor: Red Hat, Inc.
Release : 5 Build Date: Fri 07 Feb 2003 02:07:32 PM MST
Install Date: Tue 01 Jul 2003 02:19:54 PM MST
Build Host: porky.devel.redhat.com
Group : System Environment/Base?
Source RPM: crontabs-1.10-5.src.rpm
Size : 1004 License: Public Domain
Signature : DSA/SHA1, Sun 23 Feb 2003 10:41:06 PM MST,
Key ID 219180cddb42a60e
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>;
Summary : Root crontab files used to schedule the execution of programs.
Description :
The crontabs package contains root crontab files. Crontab is the
program used to install, uninstall, or list the tables used to drive the
cron daemon. The cron daemon checks the crontab files to see when
particular commands are scheduled to be executed. If commands are
scheduled, then it executes them.
You can view all of the files in a particular package installed on your system using the "-l" option:
$ rpm -ql samba /usr/bin/addtosmbpass /usr/bin/convert_smbpasswd /usr/bin/mksmbpasswd.sh /usr/bin/smbadduser /usr/bin/smbpasswd /usr/bin/smbstatus ...etc.....
You can also list all of the packages installed on your system using the "-a" option. This option will likely give you a rather extensive listing. As a result, you will generally want to grep this for something you are looking for. For example, if I wanted to search for any package that included "http" in it's name:
[hart@einstein hart]$ rpm -qa | grep http httpd-2.0.40-21.3 httpd-devel-2.0.40-21.3 libghttp-devel-1.0.9-7 httpd-manual-2.0.40-21.3 redhat-config-httpd-1.0.1-18 libghttp-1.0.9-7
For normal usage, the above commands will do most of your work. RPM has a wealth of options. The man page is a good place to study all these options and see what can work for you.
You may also find the following links of interest:
* http://rikers.org/rpmbook/ * http://rpm.org/ * http://www.rpm.org/RPM-HOWTO/
Places to find RPMs
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Places_To_Find_RPMs
Bearing in mind that deviating too much from your vendor's RPM-base is a sure-fire way to descend into "Dependency Hell", here are some great links to find RPMs:
- http://rpmfind.net/ - This is the "classic" RPM repository. It generally contains RPM-backups of every major RPM-based distro, as well as experimental RPMs from distro vendors (e.g., Mandrake Cooker) and RPMs made by application authors. It is searchable, contains archives of older RPMs, and is very extensive.
- http://freshrpms.net/ - Generally considered more "bleeding edge" than other repositories. Using this source too often when unexperienced can quickly lead to broken systems. That being said, they have great resources for setting up APT under an RPM-based system.
- http://apt-rpm.tuxfamily.org/ - Moderately reliable APT source for Red Hat systems.
- http://kitenet.net/programs/alien/ - Conversion between a number of packaging formats including RPM and DEB.
PROJECT : Install Apache
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Install_Apache
We are now going to install the Apache web-server on our system. We will not configure it or set it up (though we will in UNIX02). All we want is a working Apache install.
The name "Apache" actually comes from the web-server's original monicker "A Patchy Web-server".
Install mod-perl and any required Apache packages from the Red Hat 9 CDs. Note that Apache may be packaged as "httpd" and not "apache".
Once the system has been installed, start the web-server (usually issuing a /etc/init.d/httpd start) and browse to http://localhost/ to verify that the web-server is online.
Apache CGI Scripting Overview
Scripting For Apache
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Scripting_For_Apache
When Apache runs a server-side script, it generally takes the STDOUT from that script and outputs it to the client. Because of this, we can once again apply the old PIPE/FILE-ABSTRACTION standby's with respect to scripting for web-sites.
When a script begins, the script must first output the content type for the data it is about to send to the web-server. This can be any one of the W3C compliant MIME types (see http://www.w3.org/TR/REC-html40/types.html#h-6.7). If the script is simply sending text or html data through the server, then the following will suffice:
Content-type: text/html
Often, depending upon which scripting language is being used, this initial content type declaration will be sent automatically. Additionally, some languages such as Perl offer module libraries which will handle things like this (and producing compliant W3C code) for you. Always consult the documentation for your web-scripting language of choice before assuming one way or ther other.
Recalling our discussion of Perl in day three, we know that the print command will send data to STDOUT. Thus, the following simple script will print "Hello World!" to the web-browser:
<source lang="perl">
#!/usr/bin/perl print "Content-type: text/html\n\n"; print "<html ><body>\n";print "
print "</body></html>\n";
</source>
Go ahead and enter this into a script called "helloworld.cgi". Make it executable, and run it from the command-line to verify it works.
So now we have a Perl scrpt suitable for very simple CGI implimentation. Where do we place it?
The file /etc/httpd/conf/httpd.conf is the configuration file for Apache. We will examine it in grotesque detail in "UNIX02/Apache Configuration", but for now we are looking for the "ScriptAlias" line which defines where we install our scripts to. Chances are, it will be this:
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
So by moving this helloworld.cgi script into this directory (/var/www/cgi-bin/) we can then browse to it on our web-server using:
http://localhost/cgi-bin/helloworld.cgi
The book goes into gratuitous detail about various web-scripting options available under Linux, but this is all we will cover in this course (afterall, it really isn't a programming course in spite of the fact that there is so much scripting involved with UNIX ;-)
If you would like some great books on CGI and web programming under Linux, I highly recommend the following:
* http://www.oreilly.com/catalog/cgi2/ * http://www.oreilly.com/catalog/googlehks/ * http://www.oreilly.com/catalog/webpt2/ * http://www.oreilly.com/catalog/progphp/ * http://www.oreilly.com/catalog/phpckbk/ * http://www.oreilly.com/catalog/webdbapps/
PROJECT : Install a Simple Perl CGI
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Install_A_Simple_Perl_CGI
Install and set-up noWiki, the Wiki powering this web-site.
Obtain it from here:
* http://sourceforge.net/projects/noink
Linux Installation
In-class activity
Introduction to Kernel Recompilation
Why would I ever want to compile a kernel?
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Why_Would_I_Ever_Want_To_Compile_A_Kernel
Since the Linux OS Kernel is distributed as source, you can always recompile it and reinstall it from source. However, the Linux Kernel can be the most tricky and complicated component to build. It has a wide variety of settings and configuration options (remember, the Linux kernel has been used everywhere from tiny embedded devices, all the way up to clustered mainframes... Naturally, it will have a lot of configuration options). It is easy to make mistakes with (mistakes that are hard to track down, and which you may not discover until near the end of compilation). And it can be a time consuming task (often a kernel recompilation may take upwards of 45 to an hour, depending on options and computer speed).
So why would you ever want to recompile your kernel? Aside from the obligatory "because you can" response, there are a number of very legitimate reasons:
- Stock kernels are evil
Stock kernels (the ones that come with your distro, are generally compiled in a way to make the compatible with as much hardware as possible. This means they can be slow and sluggish. A custom built kernel often has the benefit of extra speed.
- Enterprise Support
Commercial Linux vendors have it in their interests to get you to purchase "Enterprise" level support. Chances are, however, all they really do with this support is supply you with kernels which have extra "Enterprise" level features. These features can be enabled easily (and inexpensively) by simply recompiling the kernel yourself.
- Support for Experimental Items
Whether you need IPv6 support, I2C support, or support for some latest, greatest firewire device, chances are it wont come enabled in your stock kernel. This is because many of these "newish" items are still labelled "experimental" in the kernel. "Experimental" kernel options are generally feared among distributors, and are typically turned off. If you need support for one of these things, it is often easiest to simply compile them in yourself.
- Support for Legacy Hardware
Chances are Red Hat will not support your ancient CD-ROM device powering your classic NT server. It also wont support your older ISA modem installed in your 300Mhz PII. If you want these devices to work under Linux, you may have to build a custom kernel which supports them.
Basics of Kernel Compilation
Orginal: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Basics_Of_Kernel_Compilation
Essentially, Linux Kernel recompilation is a very simple and straight-forward process. After unarchiving the Kernel source, you simply change into the newly created directory contain the source and issue the following commands:
# make clean # make mrproper # make xconifg (or some other config choice) # make dep # make bzImage # make modules # make modules_install # make install (unless you want to install the image by hand)
When you come to the config choice, that is where things get complicated. You have a variety of conifg choices, one of them is "xconfig" which presents the following graphical configuration menu:
Another is "menuconfig" which presents you with the following text-based menu:
Others include simple Q&A style configs ("Do you want 386 Support?" "Do you want to enable I2C?", etc) and even one which presents you with a text adventure ("You are standing in the forest. An Elf stands before you. The Elf asks, 'Do you want Firewire support?'").
Once in these menus, things get rather complicated. Each menu has levels of options and sub-options. Some choices enable or disable others, and some require extra code be patched in. We will not go into the details of these in this class (though, we will in "UNIX02/Kernel Recompilation"). There is also an excellent HOWTO on the subject at The Linux Documentation Project:
Compiling From Source RPM
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Compiling_From_Source_RPM
RPMs are binary packages. They contain executable binary applications built specifically for a particular architecture. Intel x86 RPMs will not run on Sparc or Motorola systems. Thus, in order for RPMs to support arbitrary systems, there exists a mechanism by which RPMs can be rebuilt for specific systems.
Source RPMs
Source RPMs are ones which contain all the source code for a particular RPM package as well as information for building that package on an arbitrary system. Source RPMs have an extension of .srpm.
When you encounter a SRPM, the comman you use to build a binary RPM is "rpmbuild". It actually has many options which can be found in the man page for it, but the only ones we will concern ourselves with are:
rpmbuild {--rebuild|--recompile} SOURCEPKG ...
When run from either of these modes, rpmbuild will build the package, compile it, and install it. In addition, --rebuild will clean out the source directory (useful if you are not planning on working with the source directly).
When finished, a binary RPM will be placed in the RPM final directory (usually under /var/lib/rpm). However, the act of building an RPM will install the RPM on your system, so the extra binary RPM is only useful if you wish to place it on another machine.
NOTE: If you are developing an application and distributing it via RPM, by building a test RPM from SRPM you will be modifying your systems RPM database and installed library. This can make testing said application more difficult, especially if your RPM clean-up scripts are not perfect.
For example, if I had an updated SRPM package for PHP, "php-4.2.2-17.2.src.rpm", I could build it and install it thusly:
# rpmbuild --rebuild php-4.2.2-17.2.src.rpm
PROJECT : Build a new Kernel
Original: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Build_A_New_Kernel
There is a new kernel update advisory from Red Hat. This updated kernel fixes several vulnerabilities found in Red Hat 9.0. You can read about these advisories here:
Download the Source RPM from this location:
And building for your system. After you have built it, upgrade your install.
Useful UNIX and Linux Links
Orginal: http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?UNIX01/Useful_UNIX_And_Linux_Links
- http://www.tldp.org/ - The Linux Documentation Project
- http://www.linux.org/
- http://www.linux.com/
- http://freshmeat.net/
- http://www.kernel.org/
- http://directory.google.com/Top/Computers/Software/Operating_Systems/Linux/
- http://directory.google.com/Top/Computers/Software/Operating_Systems/Unix/
News Sites:
