Advanced stdin, stdout and redirection

---

You've probably heard of stdout (standard out) and stdin (standard in) before but may not know what they really mean. Basically, when you run a program in the shell like 'ls' or 'grep' the output that it produces is sent to stdout, which is your terminal window. stdin is basically the opposite, instead of getting data from a file, stdin is opened up to a pipe for input to the program. If you have ever put '| less' after a command to control the amount of output you get at once, you've used stdin. By using the pipe symbol (|) you are redirecting the stdout from a program like 'ls' to the stdin of 'less'.

[user@host ~]$ ls -l | less
total 53
drwxr-xr-x   2 suso     suso         1024 Dec  7 19:10 ./
drwxr-xr-x   3 suso     suso         1024 Nov 27 06:32 ../
-rw-------   1 suso     suso        12288 Dec  7 19:21 .ioredirect.phtml.swp
-rw-r--r--   1 suso     suso         3763 Dec  6 03:44 bangcharacter.phtml
-rw-r--r--   1 suso     suso         1574 Dec  7 03:29 electricfence-readme
-rw-r--r--   1 suso     suso          127 Nov 27 06:56 footer.phtml
-rw-r--r--   1 suso     suso          219 Dec  6 00:58 header.phtml
-rw-r--r--   1 suso     suso         1496 Dec  7 03:51 index.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 19:10 ioredirect.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 02:49 jobcontrol.phtml
-rw-r--r--   1 suso     suso         5231 Dec  6 03:33 movement.phtml
-rw-r--r--   1 suso     suso         6842 Dec  7 19:09 regularexpressions.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 02:55 regularexpressions.phtml~
-rw-r--r--   1 suso     suso         3680 Dec  5 20:00 shellvariables.phtml
(END)

The output of ls is treated just like it was a file and you had typed less .

Another way you can redirect stdout is by using the angle operators, <>. If you want to send stdout to a file you use '> filename'. If you want to send the contents of a file to the stdin of a program, you can do '<>

[user@host ~]$ ls -l > listoutput
[user@host ~]$ cat listoutput
total 53
drwxr-xr-x   2 suso     suso         1024 Dec  7 19:10 ./
drwxr-xr-x   3 suso     suso         1024 Nov 27 06:32 ../
-rw-------   1 suso     suso        12288 Dec  7 19:21 .ioredirect.phtml.swp
-rw-r--r--   1 suso     suso         3763 Dec  6 03:44 bangcharacter.phtml
-rw-r--r--   1 suso     suso         1574 Dec  7 03:29 electricfence-readme
-rw-r--r--   1 suso     suso          127 Nov 27 06:56 footer.phtml
-rw-r--r--   1 suso     suso          219 Dec  6 00:58 header.phtml
-rw-r--r--   1 suso     suso         1496 Dec  7 03:51 index.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 19:10 ioredirect.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 02:49 jobcontrol.phtml
-rw-r--r--   1 suso     suso         5231 Dec  6 03:33 movement.phtml
-rw-r--r--   1 suso     suso         6842 Dec  7 19:09 regularexpressions.phtml
-rw-r--r--   1 suso     suso         3132 Dec  7 02:55 regularexpressions.phtml~
-rw-r--r--   1 suso     suso         3680 Dec  5 20:00 shellvariables.phtml
[user@host ~]$

[root@host /usr/src/linux]# patch -p1 <>
You can also append the output of a program to a file using double
greater-than signs (>>).

[root@host ~]# tail /var/log/messages
Dec  7 18:22:51 host ftpd[26820]: FTP session closed
Dec  7 18:22:52 host ftpd[26821]: ACCESS DENIED (not in any class) TO dhcp-33.domain.net [xxx.xxx.xxx.xxx]
Dec  7 18:22:52 host ftpd[26821]: FTP LOGIN REFUSED (access denied) FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:22:52 host ftpd[26821]: FTP session closed
Dec  7 18:23:04 host ftpd[26825]: FTP LOGIN FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:23:06 host ftpd[26827]: FTP LOGIN FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:26:29 host ftpd[26827]: FTP session closed
Dec  7 19:00:59 host PAM_pwdb[27479]: (su) session opened for user news by (uid=0)
Dec  7 19:01:01 host PAM_pwdb[27479]: (su) session closed for user news
Dec  7 19:59:48 host PAM_pwdb[28448]: (su) session opened for user root by suso(uid=500)
[root@host /root]# echo "Dec  7 20:00:30 host messaged: Hi Mom." >> /var/log/messages
[root@host /root]# tail /var/log/messages
Dec  7 18:22:52 host ftpd[26821]: FTP session closed
Dec  7 18:23:04 host ftpd[26825]: FTP LOGIN FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:23:06 host ftpd[26827]: FTP LOGIN FROM dhcp-33.domain.net [xxx.xxx.xxx.xxx], xxxxxxxx
Dec  7 18:26:29 host ftpd[26827]: FTP session closed
Dec  7 19:00:59 host PAM_pwdb[27479]: (su) session opened for user news by (uid=0)
Dec  7 19:01:01 host PAM_pwdb[27479]: (su) session closed for user news
Dec  7 19:59:48 host PAM_pwdb[28448]: (su) session opened for user root by suso(uid=500)
Dec  7 20:01:00 host PAM_pwdb[28639]: (su) session opened for user news by (uid=0)
Dec  7 20:01:01 host PAM_pwdb[28639]: (su) session closed for user news
Dec  7 20:00:30 host messaged[]: Hi Mom.
[root@host /root]#


There is also stderr which with is like stdout, but is the erroneous output
that comes out of a program.  Sometimes you might be redirecting the output
of a program and you will still see output in your terminal window, this is
stderr output.

[root@host /root]# ls -l /var/log /var/log/httpd/access_og > logslist
ls: /var/log/httpd/access_og: No such file or directory
[root@host /root]#


That line of output that says that the file access_og doesn't exist was sent
by the ls program to stderr, which the > doesn't catch.  If you want to catch the
output of stderr you have to use the n> notation to express which output filehandle
number you wish to use.  In the case of stderr, that number is 2.

[root@host /root]# ls -l /var/log /var/log/httpd/access_og 2> logslist
-rw-------   1 root     root      1463915 Dec  7 20:22 cron
-rw-r--r--   1 root     root         2574 Jan 30  2000 dmesg
-rw-r--r--   1 root     root            0 May  6  1999 htmlaccess.log
drwxr-xr-x   2 root     root        17408 Dec  1 00:04 httpd/
-rw-r--r--   1 root     root       157972 Dec  7 15:10 lastlog
-rw-------   1 root     root       688206 Nov 30 23:40 maillog
-rw-------   1 root     root       365531 Dec  7 20:11 messages
-rw-r--r--   1 root     root            0 Dec  1 00:04 netconf.log
-rw-------   1 root     root       561272 Dec  7 20:19 secure
-rw-r--r--   1 root     root       162275 Dec  7 04:23 spinwebd
-rw-------   1 root     root          337 Dec  7 00:04 spooler
-rw-rw-r--   1 root     utmp        92544 Dec  7 18:26 wtmp
-rw-------   1 root     root            0 Dec  1 00:04 xferlog
[root@host /root]# cat logslist
ls: /var/log/httpd/access_og: No such file or directory
[root@host /root]#


To get both the stdout and stderr to go to a file we use a combination of
> and 2>&1, which means that we want to duplicate the output of file descriptor
1 and put it on file descriptor 2.  So both stdout (1) and stderr(2) get sent
to the file 'logslist'.


$ cat food 2>&1 > file
cat: can't open food
$ cat food file 2>&1
$

Although lots of sh manual pages don't mention this, the shell reads arguments from left to right.

1. On the first command line, the shell sees 2>&1 first. That means "make the standard error (file descriptor 2) go to the same place as the standard output (fd1) is going." There's no effect because both fd2 and fd1 are already going to the terminal. Then >file redirects fd1 (stdout) to file. But fd2 (stderr) is still going to the terminal.

2. On the second command line, the shell sees >file first and redirects stdout to file. Next 2>&1 sends fd2 (stderr) to the same place fd1 is going - that's to the file. And that's what you want.

Kill process in Linux or terminate a process in UNIX or Linux systems

Q. How do I kill process in Linux?

A. Linux and all other UNIX like oses comes with kill command. The command kill sends the specified signal (such as kill process) to the specified process or process group. If no signal is specified, the TERM signal is sent.

Kill process using kill command under Linux/UNIX

kill command works under both Linux and UNIX/BSD like operating systems.

Step #1: First, you need to find out process PID (process id)

Use ps command or pidof command to find out process ID (PID). Syntax: ps aux | grep processname pidof processname

For example if process name is lighttpd, you can use any one of the following command to obtain process ID: # ps aux | grep lighttpdOutput:

lighttpd  3486  0.0  0.1   4248  1432 ?        S    Jul31   0:00 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
lighttpd  3492  0.0  0.5  13752  3936 ?        Ss   Jul31   0:00 /usr/bin/php5-cg

OR use pidof command which is use to find the process ID of a running program: # pidof lighttpdOutput:

3486

Step #2: kill process using PID (process id)

Above command tell you PID (3486) of lighttpd process. Now kill process using this PID: # kill 3486 OR # kill -9 3486 Where,

• -9 is special Kill signal, which will kill the process.

killall command examples

DO NOT USE killall command on UNIX system (Linux only command). You can also use killall command. The killall command kill processes by name (no need to find PID): # killall -9 lighttpd Kill Firefox process: # killall -9 firefox-bin As I said earlier killall on UNIX system does something else. It kills all process and not just specific process. Do not use killall on UNIX system (use kill -9).

Linux: How to Kill X windows halted, frozen or resource eating application

Q. How do I kill X windows (or application) that is not die from local or remote X sever? A. You need to use xkill command. It kills a client by its X resource and not by process ID. For example, your application may not be responding kill request. Even if you try to kill you see application window. xkill is a utility for forcing the X server to close connections to clients. This program is very dangerous, but is useful for aborting programs that have displayed undesired windows on a user's screen. Just type command xkill $ xkill And click on application which you want to abort forcefully or select the window/application whose client you wish to kill with button 1.

Kill a Frozen or Crashed UNIX / Linux X Desktop

Here is a quick tip to kill a crashed Linux / UNIX X desktop system. Many new user do not know this simple tip and end up hitting computer reboot button. Press CTRL + ALT + Backspace to kill GUI and get back to login screen. There are more ways to kill a crashed desktop without restarting your computer.

If CTRL + ALT + Backspace refused to work, try to login to console by pressing CTRL +ALT + F1. To kill GDM (Gnome Desktop) manger, enter: killall gdm You can also run the following: /etc/init.d/gdm stop To start GDM again, enter: /etc/init.d/gdm start To kill KDM (KDE Desktop), enter: killall kdm OR /etc/init.d/kdm stop To start KDM again, enter: /etc/init.d/kdm start

Disabling Unwanted Services

The list below is old (perhaps from 2006) and may only apply to Fedora Core 4 and earlier distributions. After the name of each daemon is my recommended state: on for started (enabled) and off for stopped (disabled). My recommendation is based on the kinds of services most people run (e.g. a graphical desktop machine in a home/office setting, with broadband network). The minimal set of daemons for a graphical desktop machine browsing the web and reading email is: xfs, cron, network, and syslog. You'll probably also want cups, haldaemon, iptables, and messagebus. If you are running a graphical desktop (KDE or Gnome) you must have xfs running. Is it a good idea to have cron and syslog running as well. You'll need network running to have your network active (unless you are using dial up). As far as I know, your computer will "run" without any of these daemons. The computer won't have a graphical desktop or network, but it will be running. By the same token, nearly all of these can be enabled with no problem. I don't know of a GUI application to manage daemons. Use ntsysv or chkconfig. You'll have to use a terminal window, and you must be logged in as root. chkconfig name For example: chkconfig acpid off List available daemons: chkconfig --list

• acpid - off Advanced Configuration and Power Interface event daemon. Shutdown applications if the power fails.
• aep1000 - off AEP1000/AEP2000 coprocessor driver.
• anacron - off Cron-like, but doesn't assume that the machine is always on.
• apmd - off Advanced Power Management. Only on for your UPS to shutdown your computer when the power fails.
• atd - off Run jobs queued for later execution by "at".
• autofs - off Auto mount CDs and other file system-like devices and media.
• bcm5820 - off Hardware cryptographic accelerator support for the BCM5820 Cryptonet driver.
• cpuspeed - on for laptops, off for desktop computers.
• crond - on Runs regularly scheduled system tasks, e.g. a task that runs once a day.
• cups - on Common Unix Printing System. Necesary if you want to print.
• cups-config-daemon - off(?) Works with HAL to dynamically manage printer configuration. Might overwrite /etc/cups/cupsd.conf. See: http://www.cups.org/articles.php?L301
• cxoffice - off Probably runs automatically if you have Crossover Office and run an installed Windows application.
• dc_client - off Distributed session cache client proxy.
• dc_server - off Distributed session cache server.
• gpm - off unless you want mouse cut/paste on the non-graphical console.
• haldaemon - on Auto-recognizes various kinds of hardware and mountable media.
• httpd - off The Apache web server. Only on if you need a web server.
• iptables - on The firewall.
• irda - off Infrared wireless device daemon. For PDA, etc.
• irqbalance - on If you have a multiprocessor system. Off on all single cpu machines.
• isdn - off Only used if you have an ISDN network connection.
• kudzu - off Detects and configures new and/or changed hardware on a system. Can be run manually if you need it.
• lisa - off Scans your network to provide information about hosts on your network, perhaps including Windows shares. Some versions have security problems. Part of kdenetwork utilities.
• lm_sensors - off Monitor system sensors such as CPU and motherboard temperature.
• mDNSResponder - off Publishes and browses available network services via Zeronconf (aka "Rendezvous").
• mdmonitor - off Part of the mdadm package to administer software RAID. See rpm -qi mdadm
• mdmpd - off Monitor MD multipath devices, e.g. disks with more than one controller. Apparently only for RAID arrays.
• messagebus - on Provides a communication bus for dbus. Programs talk to other programs. Probably leave enabled.
• microcode_ctl - on for Intel CPUs, off for AMD processors. Only works on Intel CPUs
• (doesn't work with AMD). I'm not clear what the updated microcode does. You can find out your cpu info on Linux systems with this command: cat /proc/cpuinfo More info at:
• http://www.urbanmyth.org/microcode/
• mysqld - off A crash prone, slow, non-standard SQL database server.
• named - off A DNS server.
• netdump - off Only for diagnosing kernel crashes.
• netfs - off Automatically Mounts and unmounts all Network File System (NFS), SMB/CIFS (Lan Manager/Windows), and NCP (NetWare) mount points. This is the only thing you need if you are an NFS client (e.g. not an NFS server), since netfs will
• run any other necessary daemons. Netfs may automatically handle everything necessary for the other (non-NFS) protocols, but I've only tested it with NFS. Disable this if you don't use NFS, Samba, or NetWare.
• netplugd - off Automatic recognition of active/inactive network interfaces.
• network - on if you have an Ethernet connection. Off for modem users.
• nfs - off Network File System. Only on to allows other unix systems to share your hard drive (volume, file system). Not necessary if you are a client to a shared volume.
• nfslock - off Provides NFS file locking functionality.Disable if you aren't using NFS. Required by nfs.
• nifd - off Network interface monitor. Calls mDNSResponder if your IP address changes.
• nscd - off Nscd provides cacheing for the passwd(5), group(5), and hosts(5) databases.
• ntpd - off Network Time Protocol. Easier to put this in cron: /usr/sbin/ntpdate -s -u ntp1.virginia.edupcmcia - on for laptop users with PCMCIA cards. Off for desktop machines.
• portmap - off Netfs will start portmap as necessary. Portmap is DARPA port to RPC program number mapper. Required if you are an nfs client or server (although netfs starts portmap for clients, so you don't need it explicitly enabled). If you're not using NFS or NIS, then you should disable portmap. Some (?) versions of portmap are highly insecure. You can run `rpcinfo -p $hostname` against your system to see what
• additional services it is providing. More info at: http://cert.uni-stuttgart.de/archive/suse/security/2003/04/msg00141.html
• postgresql - off The most powerful, fastest, easiest to use SQL database. Robust and has excellent documentation.
• psacct - off Daemon used by several utilities for monitoring process activities, including ac, lastcomm, accton, and sa.
• readahead - off The readahead process preloads the buffer cache with files that might be paged in one 'page demand triggered' read at a time. This can speed things up of boxes with enough memory. Config file is: /etc/readahead.files
• readahead_early - off See readahead. Config file is: /etc/readahead.early.files
• rhnsd - off Queries the Red Hat Network for updates and information.
• rpcgssd - off Part of the nfs-utils package. Required by nfs.
• rpcidmapd - off Required if you are running an nfs server.
• rpcsvcgssd - off Required by nfs.
• saslauthd - off unless you are using plaintext SASL password authentication
• sendmail - off Part of the mail server. Only on if you machine is mail server.
• sgi_fam - off FAM is a file monitoring daemon that detects when files have changed and then performs some action.
• smartd - off SMART Disk Monitoring Daemon. Monitor hard drive and predict failure.
• smb - off Samba Windows file sharing server.
• snmpd - off Respond to SNMP request packets. Probably only on if another machine is monitoring the status of your machine.
• snmptrapd - off Receive and log SNMP trap messages. SNMP is for monitoring system status.
• spamassassin - off Mail filter to identify spam using text analysis. Only for mail servers(?)
• squid - off Proxy caching server for web and ftp.
• sshd - off SSH daemon. On if you want to ssh into your machine.
• syslog - on Handles logging of system events. It is good to leave this turned on. Logs autorotate and will not fill your hard drive.
• tux - off Apparently a web server.
• vncserver - off Remote desktop sharing.
• winbind - off Related to Samba.
• xfs - on X Windows font server. Use by X windows to support a graphical desktop (including KDE and Gnome)
• xinetd - on Super daemon (aka super server), launches network related daemons on demand.
• ypbind - off Disabled unless you are using and NIS server, usually for password authentication
• yppasswdd - off yppasswdd is the RPC server that lets users change their passwords when you are using NIS (a.k.a. YP).
• ypserv - off ypserv is an implementation of the standard NIS/YP networking protocol.
• ypxfrd - off ypxfrd should be started in addition to ypserv to accelerate transferring yp maps.
• yum - off Yellow dog Updater, Modified. Updates software packages (rpm and/or apt
• packages). Some people run it nightly, some run it manually.
• Xinetd services in this list are typically all off. Most are totally unnecessary and several have been (or are) security holes. For a few years, Red Hat and Fedora had ftp (or vsftp) as an xinetd service. However, now vsftp is its own service (see

/etc/rc.d/init.d/). chargen - generates characters chargen-udp - udp version of chargen cups-lpd daytime - gives out the current system time daytime-udp - udp version of daytime echo - echo characters back to the client echo-udp - upb version of echo ktalk - KDE version of the talk server rsync time - RFC 868 time server. time-udp - udb version of time ------------------------------------------------------------------------------------------------------------------------

For each service listed, the Service Configuration utility will display a short description about the service you have highlighted in the upper-right pane, and the current status and process ID (PID) of the service, if it is running.

The services that you can safely disable will depend upon the role of your system. For example, if you are planning to run a web server, you will not want to disable the httpd service. The list below is a good starting place. These services can be disabled for the role we have chosen, that of a home workstation:

• aep1000 - load and unload AEP1000/AEP2000 coprocessor driver.

• bcm5820 - Hardware cryptographic accelerator support - BCM5820 Cryptonet driver.

• chargen - An xinetd internal service which generates characters.

• chargen-udp - This is the udp version.

• daytime - An internal xinetd service which gets the current system time.

• daytime-udp - This is the udp version.

• echo - An xinetd internal service which echo's characters back to clients.

• echo-udp - This is the udp version.

• httpd - Apache is a World Wide Web server. It is used to serve HTML files and CGI.

• irda - Infrared data link (for PDAs and such)

• ktalk - KDE version of the talk server.

• lisa - Provides information about hosts on your network.

• mysqld - MySQL database server.

• named - named (BIND) is a Domain Name Server (DNS) that is used to resolve host names to IP addresses.

• netplugd - netplugd is a daemon for managing non-static network interfaces.

• nfs - This service provides NFS server functionality.

• nfslock - This service provides NFS file locking functionality.

• nscd - This is a daemon which handles passwd and group lookups for running programs and cache the results for the next query.

• ntpd - ntpd is the NTPv4 daemon.

• pcmcia - PCMCIA support is usually to support things like ethernet and modems in laptops.

• rsync - allows remote file synchronization

• saslauthd - saslauthd is a server process which handles plaintext authentication requests on behalf of the cyrus-sasl library.

• sendmail - Sendmail is a Mail Transport Agent.

• services - An internal xinetd service, listing active services.

• sgi_fam - FAM is a file monitoring daemon.

• smartd - Self Monitoring and Reporting Technology (SMART) Daemon.

• snmpd - Simple Network Management Protocol (SNMP) Daemon.

• snmptrapd - Simple Network Management Protocol (SNMP) Trap Daemon.

• squid - Squid - Internet Object Cache.

• time - An RFC 868 time server.

• time-udp - This is the udp version.

• tux - The TUX threaded kernel-based http server.

• vncserver - Starts and stops vncserver. used to provide remote X administration services.

• winbind - Starts and stops the Samba winbind daemon.

• ypbind - This is a daemon which runs on NIS/YP clients and binds them to a NIS domain.

• yppasswdd - yppasswdd is the RPC server that lets users change their passwords in the presence of NIS (a.k.a. YP).

• ypserv - ypserv is an implementation of the standard NIS/YP networking protocol.

• ypxfrd - ypxfrd should be started in addition to ypserv to accelerate transferring yp maps.

• yum - Enable daily run of yum, a program updater. (This will depend on your environment.)

	Note
	If you include yum in your list of services to disable here, then you will be disabling the automated updates you would have configured in earlier sections of this overview. Certain users may have specific reasons for not wanting to run automated updates every night. Most users will want to leave this enabled, if you are disabling it, you should know exactly why.

Once you have chosen the services that you want to disable for your application, you can do so by unchecking the check box next to the name of the service you are disabling. Once you have deselected all of the services you want to disable, be sure to click the Save button, so that your changes are committed. The process needs to be done for all 3 multi user runlevels (3, 4, 5). The GUI utility defaults to runlevel 5, so you will have to manually select runlevels 3 and 4 to enable/disable service there. You may also want to check runlevel 2, as there are certain services that may be considered "critical" that will be started at that runlevel.

	Important
	Be sure to stop the service you are disabling, if it is running. This will both prevent you from having to reboot your system, as well as give you an immediate indication that stopping that particular service will inhibit any functionality you expect from the system.

Command Line: Service Configuration

	Note:
	The following commands will need to be run as root.

There are a number of ways to tackle service control from the command line. One of the simplest is to use chkconfig. The following command will show you the all of the services that are enabled to run at runlevel 5:

sudo '/sbin/chkconfig --list | awk '/5:on/ { print $1 }' | sort' 

If you are running in command line only mode (runlevel 3), theoretically, you could disable all of these services. However, this could cause problems if you were to ever run in GUI mode. So, focus on the ones that I have listed above in the GUI section. Take this list of services, and put it into a series of commands that can be run either from the command line directly, or in a script. The easiest way will be to put the list of services in a file, however you could list all of the services individually in the for loop. This might be the better option if you were running it directly from the command line.

To put the list of services in a file, issue the command above, and redirect the output to a file:

sudo '/sbin/chkconfig --list | awk '/[35]:on/ { print $1 }' | sort >> serviceslist.txt' 

This will capture all of the services that are designated to start at either runlevel 3 or runlevel 5. Then, edit the serviceslist.txt file to only disable the services you want to disable. An example serviceslist.txt file might look like this:

acpid
anacron
apmd
autofs
cpuspeed
crond
cups
cups-config-daemon
gpm
haldaemon
httpd
iptables
irqbalance
kudzu
lm_sensors
mDNSResponder
messagebus
microcode_ctl
netfs
network
nfslock
nifd
portmap
readahead
readahead_early
rhnsd
rpcgssd
rpcidmapd
rpcsvcgssd
smartd
smb
vncserver
xfs
xinetd 

Once you've edited the serviceslist.txt file, put the following into a text file, and give it executable permissions:

for SERVICE in `cat serviceslist.txt` ;do
 /sbin/chkconfig --level 35 ${SERVICE} off
done
 

Execute the script by issuing the following command:

./script.sh 

This will disable the services you have selected for runlevels 3 and 5, which are the multi-user runlevels: level 3 for command line only, and level 5 for X, or GUI, mode.

The state machine of IpTables

The state machine is a special part within iptables that should really not be called the state machine at all, since it is really a connection tracking machine. However, most people recognize it under the first name. Throughout this chapter i will use this names more or less as if they where synonymous. This should not be overly confusing. Connection tracking is done to let the Netfilter framework know the state of a specific connection. Firewalls that implement this are generally called stateful firewalls. A stateful firewall is generally much more secure than non-stateful firewalls since it allows us to write much tighter rule-sets.

Within iptables, packets can be related to tracked connections in four different so called states. These are known as NEW, ESTABLISHED, RELATED and INVALID. We will discuss each of these in more depth later. With the --state match we can easily control who or what is allowed to initiate new sessions.

All of the connection tracking is done by special framework within the kernel called conntrack. conntrack may be loaded either as a module, or as an internal part of the kernel itself. Most of the time, we need and want more specific connection tracking than the default conntrack engine can maintain. Because of this, there are also more specific parts of conntrack that handles the TCP, UDP or ICMP protocols among others. These modules grabs specific, unique, information from the packets, so that they may keep track of each stream of data. The information that conntrack gathers is then used to tell conntrack in which state the stream is currently in. For example, UDP streams are, generally, uniquely identified by their destination IP address, source IP address, destination port and source port.

In previous kernels, we had the possibility to turn on and off defragmentation. However, since iptables and Netfilter were introduced and connection tracking in particular, this option was gotten rid of. The reason for this is that connection tracking can not work properly without defragmenting packets, and hence defragmenting has been incorporated into conntrack and is carried out automatically. It can not be turned off, except by turning off connection tracking. Defragmentation is always carried out if connection tracking is turned on. All connection tracking is handled in the PREROUTING chain, except locally generated packets which are handled in the OUTPUT chain. What this means is that iptables will do all recalculation of states and so on within the PREROUTING chain. If we send the initial packet in a stream, the state gets set to NEW within the OUTPUT chain, and when we receive a return packet, the state gets changed in the PREROUTING chain to ESTABLISHED, and so on. If the first packet is not originated by ourself, the NEW state is set within the PREROUTING chain of course. So, all state changes and calculations are done within the PREROUTING and OUTPUT chains of the nat table.

The conntrack entries

Let's take a brief look at a conntrack entry and how to read them in /proc/net/ip_conntrack. This gives a list of all the current entries in your conntrack database. If you have the ip_conntrack module loaded, a cat of /proc/net/ip_conntrack might look like:

tcp      6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \
    dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \
    dport=32775 use=2
    

This example contains all the information that the conntrack module maintains to know which state a specific connection is in. First of all, we have a protocol, which in this case is tcp. Next, the same value in normal decimal coding. After this, we see how long this conntrack entry has to live. This value is set to 117 seconds right now and is decremented regularly until we see more traffic. This value is then reset to the default value for the specific state that it is in at that relevant point of time. Next comes the actual state that this entry is in at the present point of time. In the above mentioned case we are looking at a packet that is in the SYN_SENT state. The internal value of a connection is slightly different from the ones used externally with iptables. The value SYN_SENT tells us that we are looking at a connection that has only seen a TCP SYN packet in one direction. Next, we see the source IP address, destination IP address, source port and destination port. At this point we see a specific keyword that tells us that we have seen no return traffic for this connection. Lastly, we see what we expect of return packets. The information details the source IP address and destination IP address (which are both inverted, since the packet is to be directed back to us). The same thing goes for the source port and destination port of the connection. These are the values that should be of any interest to us.

The connection tracking entries may take on a series of different values, all specified in the conntrack headers available in linux/include/netfilter-ipv4/ip_conntrack*.h files. These values are dependent on which sub-protocol of IP we use. TCP, UDP or ICMP protocols take specific default values as specified in linux/include/netfilter-ipv4/ip_conntrack.h. We will look closer at this when we look at each of the protocols; however, we will not use them extensively through this chapter, since they are not used outside of the conntrack internals. Also, depending on how this state changes, the default value of the time until the connection is destroyed will also change.

Note:

Recently there was a new patch made available in iptables patch-o-matic, called tcp-window-tracking. This patch adds, among other things, all of the above timeouts to special sysctl variables, which means that they can be changed on the fly, while the system is still running. Hence, this makes it unnecessary to recompile the kernel every time you want to change the timeouts.

These can be altered via using specific system calls available in the /proc/sys/net/ipv4/netfilter directory. You should in particular look at the /proc/sys/net/ipv4/netfilter/ip_ct_* variables.

When a connection has seen traffic in both directions, the conntrack entry will erase the [UNREPLIED] flag, and then reset it. The entry tells us that the connection has not seen any traffic in both directions, will be replaced by the [ASSURED] flag, to be found close to the end of the entry. The [ASSURED] flag tells us that this connection is assured and that it will not be erased if we reach the maximum possible tracked connections. Thus, connections marked as [ASSURED] will not be erased, contrary to the non assured connections (those not marked as [ASSURED]). How many connections that the connection tracking table can hold depends upon a variable that can be set through the ip-sysctl functions in recent kernels. The default value held by this entry varies heavily depending on how much memory you have. On 128 MB of RAM you will get 8192 possible entries, and at 256 MB of RAM, you will get 16376 entries. You can read and set your settings through the /proc/sys/net/ipv4/ip_conntrack_max setting.

UNIX System Log (syslog)

Many versions of UNIX provide a general-purpose logging facility called syslog, originally developed at the University of California at Berkeley for the Berkeley sendmail program. Since then, syslog has been ported to several System V-based systems, and is now widely available. The uses of syslog have similarly been expanded.

syslog is a host-configurable, uniform system logging facility. The system uses a centralized system logging process that runs the program /etc/syslogd or /etc/syslog. Individual programs that need to have information logged send the information to syslog. The messages can then be logged to various files, devices, or computers, depending on the sender of the message and its severity.

Any program can generate a syslog log message. Each message consists of four parts:

• Program name

• Facility

• Priority

• Log message itself

For example, the message:

login: Root LOGIN REFUSED on ttya

is a log message generated by the login program. It means that somebody tried to log into an unsecure terminal as root. The messages's facility (authorization) and error level (critical error) are not shown.

The syslog facilities are summarized in Table 1, Not all facilities are present on all versions of UNIX.

Table 1: syslog Facilities

Name	Facility
kern	Kernel
user	Regular user processes
mail	Mail system
lpr	Line printer system
auth	Authorization system, or programs that ask for user names and passwords (login, su, getty, ftpd, etc.)
daemon	Other system daemons
news	News subsystem
uucp	UUCP subsystem
local0... local7	Reserved for site-specific use
mark	A timestamp facility that sends out a message every 20 minutes

The syslog priorities are summarized in Table 2

Table 10.2: syslog Priorities

Priority	Meaning
emerg	Emergency condition, such as an imminent system crash, usually broadcast to all users
alert	Condition that should be corrected immediately, such as a corrupted system database
crit	Critical condition, such as a hardware error
err	Ordinary error
warning	Warning
notice	Condition that is not an error, but possibly should be handled in a special way
info	Informational message
debug	Messages that are used when debugging programs
none	Do not send messages from the indicated facility to the selected file. For example, specifying *.debug;mail.none sends all messages except mail messages to the selected file.

When syslogd starts up, it reads its configuration file, usually /etc/syslog.conf, to determine what kinds of events it should log and where they should be logged. syslogd then listens for log messages from three sources, shown in below Table 3

Table 3: Log Message Sources

Source	Meaning
/dev/klog	Special device, used to read messages generated by the kernel
/dev/log	UNIX domain socket, used to read messages generated by processes running on the local machine
UDP port 514	Internet domain socket, used to read messages generated over the local area network from other machines

Overview of Syslog

System administrators have to deal with lots of different kinds of messages from a plethora of subsystems within each system, and usually lots of systems as well. For example, an FTP server might report every connection it gets. The kernel might report hardware failures on a disk drive. A DNS server might report usage statistics at regular intervals.

Some of these messages need to be brought to a system administrator's attention immediately. And it may not be just any system administrator – there may be a particular system administrator who deals with a particular kind of message. Other messages just need to be recorded for future reference if there is a problem. Still others may need to have information extracted from them by an automated process that generates monthly reports.

To deal with these messages, most Unix systems have a facility called "Syslog." It is generally based on a daemon called “Syslogd” Syslogd listens for messages on a Unix domain socket named /dev/log. Based on classification information in the messages and its configuration file (usually /etc/syslog.conf), Syslogd routes them in various ways. Some of the popular routings are:

• Write to the system console
• Mail to a specific user
• Write to a log file
• Pass to another daemon
• Discard

Syslogd can also handle messages from other systems. It listens on the syslog UDP port as well as the local socket for messages.

Syslog can handle messages from the kernel itself. But the kernel doesn't write to /dev/log; rather, another daemon (sometimes called “Klogd”) extracts messages from the kernel and passes them on to Syslog as any other process would (and it properly identifies them as messages from the kernel).

Syslog can even handle messages that the kernel issued before Syslogd or Klogd was running. A Linux kernel, for example, stores startup messages in a kernel message ring and they are normally still there when Klogd later starts up. Assuming Syslogd is running by the time Klogd starts, Klogd then passes everything in the message ring to it.

In order to classify messages for disposition, Syslog requires any process that submits a message to it to provide two pieces of classification information with it:

facility

This identifies who submitted the message. There are a small number of facilities defined. The kernel, the mail subsystem, and an FTP server are examples of recognized facilities. For the complete list, See syslog; vsyslog. Keep in mind that these are essentially arbitrary classifications. "Mail subsystem" doesn't have any more meaning than the system administrator gives to it.

priority

This tells how important the content of the message is. Examples of defined priority values are: debug, informational, warning, critical. For the complete list, See syslog; vsyslog. Except for the fact that the priorities have a defined order, the meaning of each of these priorities is entirely determined by the system administrator.

A “facility/priority” is a number that indicates both the facility and the priority.

Warning: This terminology is not universal. Some people use “level” to refer to the priority and “priority” to refer to the combination of facility and priority. A Linux kernel has a concept of a message “level,” which corresponds both to a Syslog priority and to a Syslog facility/priority (It can be both because the facility code for the kernel is zero, and that makes priority and facility/priority the same value).

Logging everything everywhere

Disks are cheap these days. Sites with sufficient resources and adequately trained personnel sometimes choose to log everything that might possibly be useful, and log it in many different places. For example, clients can create their own log files of syslog events, and also send all logging messages to several different logging hosts - possibly on different networks.

The advantage of logging in multiple places is that it makes an attacker's attempts at erasing any evidence of his presence much more difficult. On the other hand, multiple log files will not do you any good if they are never examined. Furthermore, if they are never pruned, they may grow so large that they will shut down your computers.

Syslog Messages

The following tables[11] summarize some typical messages available on various versions of UNIX.:

[11] A similar list is not available for System V UNIX, because syslog is part of the Berkeley UNIX offering. Companies that sell syslog with their System V offerings may or may not have modified the additional programs in their operating systems to allow them to use the syslog logging facility.

Table 10.4: Typical Critical Messages

Program	Message	Meaning
halt	halted by	used the /etc/halt command to shut down the system.
login	ROOT LOGIN REFUSED ON [FROM ]	root tried to log onto a terminal that is not secure.
login	REPEATED LOGIN FAILURES ON [FROM ]	Somebody tried to log in as and supplied a bad password more than five times.
reboot	rebooted by	rebooted the system with the /etc/reboot command.
su	BAD SU on	Somebody tried to su to the superuser and did not supply the correct password.
shutdown	reboot, halt, or shutdown by on	used the /etc/shutdown command to reboot, halt, or shut down the system.

Other critical conditions that might be present might include messages about full filesystems, device failures, or network problems.

Table 10.5: Typical Info Messages

Program	Message	Meaning
date	date set by	changed the system date.
login	ROOT LOGIN [FROM ]
	root logged in.
su	on	used the su command to become the superuser.
getty		/bin/getty was unable to open .

NOTE: For security reasons, some information should never be logged. For example, although you should log failed password attempts, you should not log the password that was used in the failed attempt. Users frequently mistype their own passwords, and logging these mistyped passwords would help a computer cracker break into a user's account. Some system administrators believe that the account name should also not be logged on failed login attempts - especially when the account typed by the user is nonexistent. The reason is that users occasionally type their passwords when they are prompted for their usernames. If invalid accounts are logged, then it might be possible for an attacker to use those logs to infer people's passwords.

You may want to insert syslog calls into your own programs to record information of importance. Third-party software also often has a capability to send log messages into the syslog if configured correctly. For example, Xyplex terminal servers and Cisco routers both can log information to a network syslog daemon; Usenet news and POP mail servers also log information.

If you are writing shell scripts, you can also log to syslog. Usually, systems with syslog come with the logger command. To log a warning message about a user trying to execute a shell file with invalid parameters, you might include:

logger -t ThisProg -p user.notice "Called without required # of parameters"

NOTE: Prior to 1995, many versions of the syslog library call did not properly check their inputs to be certain that the data would fit into the function's internal buffers. Thus, many programs could be coerced to accept input to write arbitrary data over their stacks, leading to potential compromise. Be certain that you are running software using a version of syslog that does not have this vulnerability.

Beware false log entries

The UNIX syslog facility allows any user to create log entries. This capability opens up the possibility for false data to be entered into your logs. An interesting story of such logging was given to us by Alec Muffet:

A friend of mine - a UNIX sysadmin - enrolled as a mature student at a local polytechnic in order to secure the degree which had been eluding him for the past four years.

One of the other students on his Computer Science course was an obnoxious geek user who was shoulder surfing people and generally making a nuisance of himself, and so my friend determined to take revenge.

The site was running an early version of Ultrix on an 11/750, but the local operations staff were somewhat paranoid about security, had removed world execute from "su" and left it group-execute to those in the wheel group, or similar; in short, only the sysadmin staff should have execute access for su.

Hence, the operations staff were somewhat worried to see messages with the following scrolling up the console:

  BAD SU: geekuser ON ttyp4 AT 11:05:20
 BAD SU: geekuser ON ttyp4 AT 11:05:24
 BAD SU: geekuser ON ttyp4 AT 11:05:29
 BAD SU: geekuser ON ttyp4 AT 11:05:36
 ...

When the console eventually displayed:

  SU: geekuser ON ttyp4 AT 11:06:10

all hell broke loose: the operations staff panicked at the thought of an undergrad running around the system as root and pulled the plug (!) on the machine. The system administrator came into the terminal room, grabbed the geekuser, took him away and shouted at him for half an hour, asking (a) why was he hacking, (b) how was he managing to execute su and (c) how he had guessed the root password?

Nobody had noticed my friend in the corner of the room, quietly running a script which periodically issued the following command, redirected into /dev/console, which was world-writable:

  echo BAD SU: geekuser ON ttyp4 AT `date` 

The moral of course is that you shouldn't panic, and that you should treat your audit trail with suspicion.

Proxy ARP

Introduction This document explains the concept of proxy Address Resolution Protocol (ARP). Proxy ARP is the technique in which one host, usually a router, answers ARP requests intended for another machine. By "faking" its identity, the router accepts responsibility for routing packets to the "real" destination. Proxy ARP can help machines on a subnet reach remote subnets without the need to configure routing or a default gateway. Proxy ARP is defined in RFC 1027 leavingcisco.com. The Host A (172.16.10.100) on Subnet A needs to send packets to Host D (172.16.20.200) on Subnet B. As shown in the diagram, Host A has a /16 subnet mask. What this means is that Host A believes that it is directly connected to all of network 172.16.0.0. When Host A needs to communicate with any devices it believes are directly connected, it sends an ARP request to the destination. Therefore, when Host A needs to send a packet to Host D, Host A believes that Host D is directly connected, so it sends an ARP request to Host D. Therefore, Host A broadcasts an ARP request on Subnet A, as shown:

Sender's MAC Address	Sender's IP Address	Target MAC Address	Target IP Address
00-00-0c-94-36-aa	172.16.10.100	00-00-00-00-00-00	172.16.20.200

In this ARP request, Host A (172.16.10.100) requests that Host D (172.16.20.200) send its MAC address. The ARP request packet is then encapsulated in an Ethernet frame with the MAC address of Host A as the source address and a broadcast (FFFF.FFFF.FFFF) as the destination address. Since the ARP request is a broadcast, it reaches all the nodes in the Subnet A, which includes the e0 interface of the router, but does not reach Host D. The broadcast does not reach Host D because routers, by default, do not forward broadcasts.

Since the router knows that the target address (172.16.20.200) is on another subnet and can reach Host D, it replies with its own MAC address to Host A.

Sender's MAC Address	Sender's IP Address	Target MAC Address	Target IP Address
00-00-0c-94-36-ab	172.16.20.200	00-00-0c-94-36-aa	172.16.10.100

This is the Proxy ARP reply that the router sends to Host A. The proxy ARP reply packet is encapsulated in an Ethernet frame with MAC address of the router as the source address and the MAC address of Host A as the destination address. The ARP replies are always unicast to the original requester.

Upon receit of this ARP reply, Host A updates its ARP table, as shown:

IP Address	MAC Address
172.16.20.200	00-00-0c-94-36-ab

From now on, Host A forwards all the packets that it wants to reach 172.16.20.200 (Host D) to the MAC address 00-00-0c-94-36-ab (router). Since the router knows how to reach Host D, the router forwards the packet to Host D. The ARP cache on the hosts in Subnet A is populated with the MAC address of the router for all the hosts on Subnet B. Hence, all packets destined to Subnet B are sent to the router. The router forwards those packets to the hosts in Subnet B.

The ARP cache of Host A is shown in this table:

IP Address	MAC Address
172.16.20.200	00-00-0c-94-36-ab
172.16.20.100	00-00-0c-94-36-ab
172.16.10.99	00-00-0c-94-36-ab
172.16.10.200	00-00-0c-94-36-bb

Note: Multiple IP addresses are mapped to a single MAC address, the MAC address of this router, which indicates that proxy ARP is in use.

Note: When Host B (172.16.10.200/24) on Subnet A tries to send packets to destination Host D (172.16.20.200) on Subnet B, it looks into its IP routing table and routes the packet accordingly. Host B (172.16.10.200/24) does not ARP for Host D IP address 172.16.20.200 because it belongs to a different subnet than what is configured on Host B ethernet interface 172.16.20.200/24.

Advantages of Proxy ARP

The main advantage of proxy ARP is that it can be added to a single

router on a network and does not disturb the routing tables of the other routers on the network.

Proxy ARP must be used on the network where IP hosts are not configured

with a default gateway or do not have any routing intelligence.

Disadvantages of Proxy ARP

Hosts have no idea of the physical details of their network and assume

it to be a flat network in which they can reach any destination simply by sending an ARP request. But using ARP for everything has disadvantages. These are some of the disadvantages:

• It increases the amount of ARP traffic on your segment.
• Hosts need larger ARP tables in order to handle IP-to-MAC address mappings.
• Security can be undermined. A machine can claim to be another in order to intercept packets, an act called "spoofing."
• It does not work for networks that do not use ARP for address resolution.
• It does not generalize to all network topologies. For example, more than one router that connects two physical networks.

Redirectoin in LINUX ,>,>>

What is Redirection and How Does it Work?

Redirecting the Input or Output of Linux Commands

Another useful bash feature is its ability to redirect the input and output of Linux commands. You can save the results of a command in a file instead of displaying the results on the screen, or you can feed data from a file to a program instead of entering data from the keyboard.Let's look at redirection first. Imagine a fictitious command called nocats that prompts the user for a number and then waits for that many lines of text to be entered before processing them. (The program looks at each input line and pr ints only the ones that do not contain the word cat.)

You could feed the program by entering the data from the console (bold text is your typed input, normal text is console output):

$ nocats 3 Dogs are much better than those other household animals. A cat would never beg for jerky treats. Dogs are pretty stupid, but at least they stick around. Dogs are much better than those other household animals. Dogs are pretty stupid, but at least they stick around.

Or using a text editor, you could put all the input data in a file called stuff and feed the nocats program like this:

% nocats Dogs are much better than those other household animals. Dogs are pretty stupid, but at least they stick around.

The less-than (<) symbol causes the program to get input from the stuff file instead of waiting for keyboard input. The greater-than (>) symbol, on the other hand, redirects output to a file instead of to the console. Thus, the co mmand

% nocats <> bother

will cause the nocats program to read its input from one file (stuff) and write it to another (bother), without the keyboard or console entering the picture. Note that the nocats progra m doesn't know or care about all this redirection. It still thinks it is reading data from the keyboard and writing to the console--but the shell has temporarily reassigned the input and output to files instead of physical devices.

To append to an existing file instead of creating a new one, use two greater-than symbols (>>), as in this example:

zippity > somefile doodah >> somefile

The zippity command runs first, and the output is placed in a new file called somefile. Then doodah runs, and its output is added (appended) to the somefile file.

Note: It's important to remember that piping with a single > symbol will wipe out existing data if the output file already exists.

How Do I Use the Linux Command Prompt?

Linux Commands

When you enter a command in Linux, you type a command at a prompt and then press enter. Commands can be more than one word--some require switches (which modify the command's behavior ) and/or file names (which tell the command what data to act on). Let's dissect the command shown here:$ ls -l sample.doc

Linux Commands Are Case Sensitive

One of the most important things to remember about entering commands in any Unix environment is that case matters. In DOS, you can type DIR or dir or even DiR and get the same result, but not in Linux. Linux will be quite put out if you type LS instead of ls to list your files. With file names, you have to be even more careful, since nearly identical files (save for capitalization) can exist in the same directory, though they may have completely different contents--Cookie_Recipe and cookie_recipe would appear as distinctly different files to Linux, though they may look pretty much the same to you except for the capital letters.

The best rule to follow is this: Almost everything in Linux is lowercase, so avoid capital letters when naming your files.

Command Prompts Can Vary

When the Linux shell is ready for a command, you see a command prompt. Just as in DOS, Linux's command prompts vary. For example, when you log in as root, your default command prompt is the pound (#) sign, but if you log-in as a regula r user (like hermie), the prompt changes to a dollar sign ($).

Bash uses the different prompts to clue you in to your user privileges. Pay attention to the prompts so you don't inadvertently wipe out important files while logged in to the root account with superuser privileges, for example.

It's especially important to mind the prompts if you use the su (switch user) command, which allows you to act temporarily as the root user while you're logged in as a regular user. Watch how the prompt changes in the following example. (User input is in boldface.)

$ who am i hermie $ su - root Enter password for root: xxxxxxx # who am i root # exit $ who am i hermie

In this example, entering the command who am i tells you who the system thinks you are--hermie. Then the su - root command switches you to the root user (note the prompt change to the pound sign). The <>exit command exits the root user account and brings you back to hermie; the prompt changes back to a dollar sign. (See "Important Linux Commands" for more information on the su comma nd.)

This example used the prompt and the who am i command to show the logged-in user, but customizing your prompt is a better way to keep track of where you are.

For example, the command

PS1="\u \$ "

changes the prompt so that it displays the user name (\u), followed by the dollar sign (or pound sign, if you're a superuser). You can use other characters to insert the current time, date, or working directory (\t, \d, and \w, respectively). Here's how to use these various options:

PS1="\t \$ " yields 09:15:24 $.

PS1="\u (\d) \$ " yields hermie (Wed Nov 4) $.

PS1="\u (\w) \$ " yields hermie (/home/hermie) $.

All you're actually doing here is setting the variable PS1 (prompt string number 1) to a special string of characters. The bash shell interprets the value of the PS1 variable each time it's ready to build the prompt string.

In the "Environment Variables

" section, you'll learn more about special variables such as PS1 and how to set them automatically each time you log in.

LINUX INTRODUCTION

I know i should have this long time back, now i am posting this as i think this is intro about LiNUX is quite Good....

Can Linux Replace Windows?

Until recently, running Unix meant investing in a powerful workstation that cost megabucks. Linux changes all that, because it's a complete version of the Unix operating system (software that controls the basic functions of the personal computer) that runs on ordinary personal computers. The added fact that it's freely available and "open source" makes it all the more attractive.Linux is perfect for people who want to operate their own low-cost Internet servers, and it's robust enough to satisfy the needs of many Internet service providers. Linux is a multiuser and multitasking environment, and it can access huge amounts of me mory (gigabytes) and huge amounts of disk storage space (terabytes). Linux offers virtually everything that Windows has been promising for years and may not deliver in a truly stable form for some time to come.

Don't make the mistake of assuming that Linux is some kind of watered-down or underpowered Unix for the masses. Linux is Unix. POSIX certification (compliance with the industry standards for Unix) makes it official that Linux can do everything that a Unix system is supposed to do. The only difference is that Linux works on a personal computer, whereas other versions of Unix run on larger workstations or mainframes.

Linux is also being taken very seriously by the computer industry, with new Linux-compatible versions of popular software packages being announced every month. The Apache Web server software running on Linux platforms powers about half of all Web sites today. Even more telling, Microsoft considers Linux a major threat to its Windows empire.

What Is Linux?

In the early 90s, a geek named Linus Torvalds at the University of Helsinki in Finland thought it would be fun to write a Unix kernel from scratch. He called it Linux, and it was cool but pretty much useless without all the utility programs needed to make it a complete operating system. At the same time, Richard Stallman and his pals at the Free Software Foundation were writing a bunch of freeware Unix utilities collectively known as the GNU Project. It was cool but pretty much useless without a kernel to make it a complete operating system. Fortunately, the two parties decided to collaborate.

News of Linux spread quickly over the Internet, and many other Unix programmers joined the effort to enhance it. What we now know as Linux is a combination of Torvald's Linux kernel, the GNU Project software, and some other nifty software bit and pieces developed by programmers from all around the world.

Today Linux is a complete and reliable implementation of the Unix operating system, with the following notable features:

• 32-bit operation (it uses all the speed and power of your CPU, unlike 16-bit DOS systems)
• Virtual memory (it can use all of your system's RAM; there's no 640K memory limit)
• Full support for X Windows (Unix's standard graphical user interface)
• TCP/IP networking support (allowing connection to the Internet)
• GNU software support (including a huge amount of free Unix software from the GNU Project)

Note: GNU is one of those recursive acronyms that computer scientists love; it stands for GNU's Not Unix. The GNU Project is an effort sponsored by the Free Software Foundation to provide freely available Unix software. See http://www.gnu.org for related information.

Linux was written totally from scratch without using any of the original AT&T UNIX code. (Throughout this site, UNIX refers to the original trademarked UNIX project invented by AT&T. The term Unix is used here as a generic term for other variants of the operating system.)

Because of that (and because the author is a nice guy), Linux is free. You can obtain the source code, modify, sell or give away the software so long as you provide full source code and don't impose any restrictions on what others do with it.

How Do I Set and Use Linux Environment Variables?

Environment Variables

Environment variables in the bash shell help you in several ways. Certain built-in variables change the shell in ways that make your life a little easier, and you can define other variables to suit your own purposes. Here are some examples of built-in shell variables:· PS1 defines the shell's command-line prompt.

· HOME defines the home directory for a user.

· PATH defines a list of directories to search through when looking for a command to execute.

To list the current values of all environment variables, issue the command

env

or list a specific variable with the echo command, prefixing the variable n ame with a dollar sign (the second line shows the result of the echo command):

echo $HOME /home/hermie

You've already learned how to customize your shell prompt with the PS1 variable. The HOME variable is one you shouldn't mess with, because lots of programs count on it to create or find files in your personal home directory.

Understanding the Path Variable

As in DOS, the shell uses the PATH variable to locate a command. PATH contains a list of dir ectories separated by colons:

echo $PATH /bin:/usr/bin:/usr/local/bin

When you enter a command, the shell looks in each of the directories specified in PATH to try to find it. If it can't find the command in any of those directories, you'll see a "Command not found" message.

If you decide to put your own programs in a bin directory under your home directory, you'll have to modify the path to include that directory, or the system will never find your programs (unless you happen to be in that directory when you enter the command). Here's how to change your PATH variable so it includes your personal bin directory:

PATH=$PATH:$HOME/bin

So if PATH was set to /bin:/usr/bin:/usr/local/bin beforehand, it would now have the value /bin:/usr/bin:/usr/local/bin:/home/hermie/bin.

Creating Your Own Shell Variables

If you are a programmer, you'll find it handy to create your own shell variables. First issue the command

code=$HOME/projects/src/spew

and then, regardless of what directory you are in, you can issue

cd $code

to pop over quickly to the directory containing the source code for that way-cool spew program you're developing. (The cd command means "change directory.")

A variable assignment like this will work just fine, but its scope (visibility) is limited to the current shell. If you launch a program or enter another shell, that child task will not know about your environment variables unless you export them first.

Unless you know for sure that an environment variable will have meaning only in the current shell, it's a good idea to always use export when creating variables to ensure they will be global in scope--for example,

export PS1="\u \$ " export code=$HOME/projects/src/spew

And be sure to add these commands to your .profile file so you won't have to retype them eac h time you log in.

Adding a Directory to the Path

Pre and Post Pathing

Linux determines the executable search path with the $PATH environment variable. To add directory /data/myscripts to the beginning of the $PATH environment variable, use the following:

PATH=/data/myscripts:$PATH

To add that directory to the end of the path, use the following command:

PATH=$PATH:/data/myscripts

But the preceding are not sufficient because when you set an environment variable inside a script, that change is effective only within the script. There are only two ways around this limitation:

1. If, within the script, you export the environment variable it is effective within any programs called by the script. Note that it is not effective within the program that called the script.
2. If the program that calls the script does so by inclusion instead of calling, any environment changes in the script are effective within the calling program. Such inclusion can be done with the dot command or the source command. Examples: . $HOME/myscript.sh source $HOME/myscript.sh

Inclusion basically incorporates the "called" script in the "calling" script. It's like a #include in C. So it's effective inside the "calling" script or program. But of course, it's not effective in any programs or scripts called by the calling program. To make it effective all the way down the call chain, you must follow the setting of the environment variable with an export command. As an example, the bash shell program incorporates the contents of file .bash_profile by inclusion. So putting the following 2 lines in .bash_profile:

PATH=$PATH:/data/myscripts
export PATH

effectively puts those 2 lines of code in the bash program. So within bash the $PATH variable includes $HOME/myscript.sh, and because of the export statement, any programs called by bash have the altered $PATH variable. And because any programs you run from a bash prompt are called by bash, the new path is in force for anything you run from the bash prompt. The bottom line is that to add a new directory to the path, you must append or prepend the directory to the $PATH environment variable within a script included in the shell, and you must export the $PATH environnment variable. The only remaining question is: In which script do you place those two lines of code?

Adding to a Single User's Path

To add a directory to the path of a single user, place the lines in that user's .bash_profile file. Typically, .bash_profile already contains changes to the $PATH variable and also contains an export statement, so you can simply add the desired directory to the end or beginning of the existing statement that changes the $PATH variable. However, if .bash_profile doesn't contain the path changing code, simply add the following two lines to the end of the .bash_profile file:

PATH=$PATH:/data/myscripts
export PATH

Adding to All Users' Paths (except root)

You globally set a path in /etc/profile. That setting is global for all users except user root. Typical /etc/profile files extensively modify the $PATH variable, and then export that variable. What that means is you can modify the path by appending or prepending the desired directory(s) in existing statements modifying the path. Or, you can add your own path modification statements anywhere before the existing export statement. In the very unlikely event that there are no path modification or export statements in /etc/profile, you can insert the following 2 lines of code at the bottom of /etc/profile:

PATH=$PATH:/data/myscripts
export PATH

Adding to the Path of User root

User root is a special case, at least on Mandrake systems. Unlike other users, root is not affected by the path settings in /etc/profile. The reason is simple enough. User root's path is set from scratch by its .bash_profile script. In order to add to the path of user root, modify its .bash_profile.

Summary

A fundimental administration task is adding directories to the execution paths of one or more users. The basic code to do so is:

PATH=$PATH:/data/myscripts
export PATH

Place that code, or whatever part of that code isn't already incorporated, in one of the following places:

User Class	Script to modify
One user	$HOME/.bash_profile
All users except root	/etc/profile
root	/root/.bash_profile