File: x134.html

package info (click to toggle)
sysadmin-guide 0.8-2
links: PTS
area: main
in suites: etch, etch-m68k, sarge
size: 840 kB
ctags: 2
sloc: makefile: 27; sh: 12
file content (850 lines) | stat: -rw-r--r-- 17,085 bytes
<HTML
><HEAD
><TITLE
>Major services in a UNIX system</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="The Linux System Administrator's Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="Overview of a Linux System"
HREF="c102.html"><LINK
REL="PREVIOUS"
TITLE="Important parts of the kernel"
HREF="x123.html"><LINK
REL="NEXT"
TITLE="Overview of the Directory Tree"
HREF="dir-tree-overview.html"></HEAD
><BODY
CLASS="sect1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Linux System Administrator's Guide: </TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x123.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 3. Overview of a Linux System</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="dir-tree-overview.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN134"
></A
>3.3. Major services in a UNIX system</H1
><P
>This section describes some of the more important UNIX
	services, but without much detail.  They are described more
	thoroughly in later chapters.</P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN137"
></A
>3.3.1. <B
CLASS="command"
>init</B
></H2
><P
>The single most important service in a UNIX system is
	provided by <B
CLASS="command"
>init</B
>.  <B
CLASS="command"
>init</B
>
	is started as the first process of every UNIX system, as the last
	thing the kernel does when it boots.  When <B
CLASS="command"
>init</B
>
	starts, it continues the boot process by doing various startup
	chores (checking and mounting filesystems, starting daemons,
	etc).</P
><P
>The exact list of things that <B
CLASS="command"
>init</B
>
	does depends on which flavor it is; there are several to choose
	from.  <B
CLASS="command"
>init</B
> usually provides the concept of
	<I
CLASS="glossterm"
>single user mode</I
>, in which no one can
	log in and root uses a shell at the console; the usual mode is
	called <I
CLASS="glossterm"
>multiuser mode</I
>.  Some flavors
	generalize this as <I
CLASS="glossterm"
>run levels</I
>; single
	and multiuser modes are considered to be two run levels, and
	there can be additional ones as well, for example, to run X on
	the console.</P
><P
>Linux allows for up to 10
	<I
CLASS="glossterm"
>runlevels</I
>, 0-9, but usually only some of
	these are defined by default.  Runlevel 0 is defined as <SPAN
CLASS="QUOTE"
>"system
	halt"</SPAN
>.  Runlevel 1 is defined as <SPAN
CLASS="QUOTE"
>"single user mode"</SPAN
>.
	Runlevel 6 is defined as <SPAN
CLASS="QUOTE"
>"system reboot"</SPAN
>.  Other runlevels are
	dependent on how your particular distribution has defined them,
	and they vary significantly between distributions.  Looking at 
	the contents of <TT
CLASS="filename"
>/etc/inittab</TT
> usually will
	give some hint what the predefined runlevels are and what they
	have been defined as.</P
><P
>In normal operation, <B
CLASS="command"
>init</B
> makes sure
	<B
CLASS="command"
>getty</B
> is working (to allow users to log in),
	and to adopt orphan processes (processes whose parent has died; in
	UNIX <EM
>all</EM
> processes <EM
>must</EM
>
	be in a single tree, so orphans must be adopted).</P
><P
>When the system is shut down, it is <B
CLASS="command"
>init</B
>
	that is in charge of killing all other processes, unmounting all
	filesystems and stopping the processor, along with anything else
	it has been configured to do.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN163"
></A
>3.3.2. Logins from terminals</H2
><P
>Logins from terminals (via serial lines) and the console
	(when not running X) are provided by the <B
CLASS="command"
>getty</B
>
	program.  <B
CLASS="command"
>init</B
> starts a separate instance of
	<B
CLASS="command"
>getty</B
> for each terminal upon which logins are to
	be allowed.  <B
CLASS="command"
>getty</B
> reads the username and runs
	the <B
CLASS="command"
>login</B
> program, which reads the password.  If
	the username and password are correct, <B
CLASS="command"
>login</B
> runs
	the shell. When the shell terminates, i.e., the user logs out, or
	when <B
CLASS="command"
>login</B
> terminated because the username and
	password didn't match, <B
CLASS="command"
>init</B
> notices this and
	starts a new instance of <B
CLASS="command"
>getty</B
>. The kernel has no
	notion of logins, this is all handled by the
	<I
CLASS="glossterm"
>system programs</I
>.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN176"
></A
>3.3.3. Syslog</H2
><P
>The kernel and many <I
CLASS="glossterm"
>system programs</I
>
	produce error, warning, and other messages.  It is often important
	that these messages can be viewed later, even much later, so they
	should be written to a file.  The program doing this is
	<B
CLASS="command"
>syslog</B
>.  It can be configured to sort the
	messages to different files according to writer or degree of
	importance.  For example, kernel messages are often directed to a
	separate file from the others, since kernel messages are often more
	important and need to be read
	regularly to spot problems.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN181"
></A
>3.3.4. Periodic command execution: <B
CLASS="command"
>cron</B
> and
<B
CLASS="command"
>at</B
></H2
><P
>Both users and system administrators often need
	to run commands periodically.  For example, the system administrator
	might want to run a command to clean the directories with temporary
	files (<TT
CLASS="filename"
>/tmp</TT
> and <TT
CLASS="filename"
>/var/tmp</TT
>)
	from old files, to keep the disks from filling up, since not all
	programs clean up after
	themselves correctly.</P
><P
>The <B
CLASS="command"
>cron</B
> service is set up to do this.
	Each user can have a <TT
CLASS="filename"
>crontab</TT
> file, where she
	lists the commands she wishes to execute and the times they should
	be executed.  The <B
CLASS="command"
>cron</B
> daemon takes care of
	starting the commands when specified.</P
><P
>The <B
CLASS="command"
>at</B
> service is similar to
	<B
CLASS="command"
>cron</B
>, but it is once only: the command is
	executed at the given time, but it is not repeated.</P
><P
>See the manual pages cron(1), crontab(1), crontab(5), at(1) and
	atd(8) for more in depth information.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN196"
></A
>3.3.5. Graphical user interface</H2
><P
>UNIX and Linux don't incorporate the user interface
	into the kernel; instead, they let it be implemented by user level
	programs.  This applies for both text mode and graphical
	environments.</P
><P
>This arrangement makes the system more flexible, but has
	the disadvantage that it is simple to implement a different user
	interface for each program, making the system harder to
	learn.</P
><P
>The graphical environment primarily used with Linux
	is called the X Window System (X for short).  X also does
	not implement a user interface; it only implements a window
	system, i.e., tools with which a graphical user interface can
	be implemented.  Some popular window managers are: fvwm, icewm,
	blackbox and windowmaker.  There are also two popular desktop
	managers, KDE and Gnome.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN201"
></A
>3.3.6. Networking</H2
><P
>Networking is the act of connecting two or more computers
	so that they can communicate with each other.  The actual methods
	of connecting and communicating are slightly complicated, but
	the end result is very useful.</P
><P
>UNIX operating systems have many networking features.
	Most basic services (filesystems, printing, backups, etc) can
	be done over the network.  This can make system administration
	easier, since it allows centralized administration, while
	still reaping in the benefits of microcomputing and distributed
	computing, such as lower costs and better fault tolerance.</P
><P
>However, this book merely glances at networking; see the
	<I
CLASS="citetitle"
>Linux Network Administrators' Guide</I
>
	<A
HREF="http://www.tldp.org/LDP/nag2/index.html"
TARGET="_top"
>&#13;	http://www.tldp.org/LDP/nag2/index.html</A
> for
	more information, including a basic description of how networks
	operate.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN208"
></A
>3.3.7. Network logins</H2
><P
>Network logins work a little differently than normal logins.
	There is a separate physical serial line for each terminal via
	which it is possible to log in.  For each person logging in via
	the network, there is a separate virtual network connection,
	and there can be any number of these.
	
		<A
NAME="AEN211"
HREF="#FTN.AEN211"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
>
		
	It is therefore not possible to run a separate
	<B
CLASS="command"
>getty</B
> for each possible virtual connection.
	There are also several different ways to log in via a network,
	<B
CLASS="command"
>telnet</B
> and <B
CLASS="command"
>rlogin</B
> being
	the major ones in TCP/IP networks.
		<A
NAME="AEN216"
HREF="#FTN.AEN216"
><SPAN
CLASS="footnote"
>[2]</SPAN
></A
>
	</P
><P
>Network logins have, instead of a herd of
	<B
CLASS="command"
>getty</B
>s, a single daemon per way of logging in
	(<B
CLASS="command"
>telnet</B
> and <B
CLASS="command"
>rlogin</B
> have
	separate daemons) that listens for all incoming login attempts.
	When it notices one, it starts a new instance of itself to
	handle that single attempt; the original instance continues to
	listen for other attempts.  The new instance works similarly
	to <B
CLASS="command"
>getty</B
>.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN231"
></A
>3.3.8. Network file systems</H2
><P
>One of the more useful things that can be done with
	networking services is sharing files via a <I
CLASS="glossterm"
>network
	file system</I
>.  The one usually used is called the
	Network File System, or NFS, developed by Sun.</P
><P
>With a network file system any file operations done by
	a program on one machine are sent over the network to another
	computer.  This fools the program to think that all the files
	on the other computer are actually on the computer the program
	is running on.	This makes information sharing extremely simple,
	since it requires no modifications to programs.</P
><P
>Another popular way of sharing files is Samba <A
HREF="http://www.samba.org"
TARGET="_top"
>http://www.samba.org</A
>.  This
	protocol allows the sharing of files with MS Windows machines
	(via Network Neighbourhood).  It also allows the sharing of
	printers across machines.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN238"
></A
>3.3.9. Mail</H2
><P
>Electronic mail is the most popularly used method for
	communicating via computer.  An electronic letter is stored in a
	file using a special format, and special mail programs are used
	to send and read the letters.</P
><P
>Each user has an <I
CLASS="glossterm"
>incoming mailbox</I
>
	(a file in the special format), where all new mail is stored.
	When someone sends mail, the mail program locates the receiver's
	mailbox and appends the letter to the mailbox file.  If the
	receiver's mailbox is in another machine, the letter is sent to
	the other machine, which delivers it to the mailbox as it best
	sees fit.</P
><P
>The mail system consists of many programs.  The
	delivery of mail to local or remote mailboxes is done by one
	program (the <I
CLASS="glossterm"
>mail transfer agent</I
> (MTA), 
	e.g., <B
CLASS="command"
>sendmail</B
>
	or <B
CLASS="command"
>smail</B
>), while the programs users use
	are many and varied (<I
CLASS="glossterm"
>mail user agent</I
> (MUA),
	e.g., <B
CLASS="command"
>pine</B
>, <B
CLASS="command"
>mutt</B
>
	or <B
CLASS="command"
>elm</B
>).  The mailboxes are usually stored
	in <TT
CLASS="filename"
>/var/spool/mail</TT
>.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN252"
></A
>3.3.10. Printing</H2
><P
>Only one person can use a printer at one time, but it is
	uneconomical not to share printers between users.  The printer is
	therefore managed by software that implements a <I
CLASS="glossterm"
>print
	queue</I
>: all print jobs are put into a queue and
	whenever the printer is done with one job, the next one is sent
	to it automatically.  This relieves the users from organizing
	the print queue and fighting over control of the printer.
		<A
NAME="AEN256"
HREF="#FTN.AEN256"
><SPAN
CLASS="footnote"
>[3]</SPAN
></A
>
	</P
><P
>The print queue software also <I
CLASS="glossterm"
>spools</I
>
	the printouts on disk, i.e., the text is kept in a file while
	the job is in the queue.  This allows an application program
	to spit out the print jobs quickly to the print queue software;
	the application does not have to wait until the job is actually
	printed to continue.  This is really convenient, since it
	allows one to print out one version, and not have to wait for
	it to be printed before one can make a completely revised new
	version.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN261"
></A
>3.3.11. The filesystem layout</H2
><P
>The filesystem is divided into many parts;
	usually along the lines of a root filesystem with
	<TT
CLASS="filename"
>/bin</TT
>, <TT
CLASS="filename"
>/lib</TT
>,
	<TT
CLASS="filename"
>/etc</TT
>, <TT
CLASS="filename"
>/dev</TT
>, and
	a few others; a <TT
CLASS="filename"
>/usr</TT
> filesystem with
	programs and unchanging data; a <TT
CLASS="filename"
>/var</TT
>
	filesystem with changing data (such as log files); and a
	<TT
CLASS="filename"
>/home</TT
> filesystem for everyone's personal
	files.	Depending on the hardware configuration and the decisions
	of the system administrator, the division can be different;
	it can even be all in one filesystem.</P
><P
><A
HREF="dir-tree-overview.html"
>Chapter 4</A
> describes the filesystem
	layout in some little detail; the Filesystem Hierarchy Standard covers it
	in somewhat more detail.
		<A
NAME="AEN273"
HREF="#FTN.AEN273"
><SPAN
CLASS="footnote"
>[4]</SPAN
></A
>
	</P
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN211"
HREF="x134.html#AEN211"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>Well, at least there can be many.  Network
		bandwidth still being a scarce resource, there is still
		some practical upper limit to the number of concurrent
		logins via one network connection.  </P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN216"
HREF="x134.html#AEN216"
><SPAN
CLASS="footnote"
>[2]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>These days many Linux system administrators 
		consider <B
CLASS="command"
>telnet</B
> and <B
CLASS="command"
>rlogin
		</B
> to be insecure and prefer <B
CLASS="command"
>ssh
		</B
>, the <SPAN
CLASS="QUOTE"
>"secure shell"</SPAN
>, which encrypts traffic 
		going over the network, thereby making it far less likely 
		that the malicious can <SPAN
CLASS="QUOTE"
>"sniff"</SPAN
> your connection and gain 
		sensitive data like usernames and passwords.  It is
		highly recommended you use <B
CLASS="command"
>ssh</B
> rather than
		<B
CLASS="command"
>telnet</B
> or <B
CLASS="command"
>rlogin</B
>.  
		</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN256"
HREF="x134.html#AEN256"
><SPAN
CLASS="footnote"
>[3]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>Instead, they form a new queue
		<EM
>at</EM
> the printer, waiting for their
		printouts, since no one ever seems to be able to get the
		queue software to know exactly when anyone's printout is
		really finished.  This is a great boost to intra-office
		social relations.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN273"
HREF="x134.html#AEN273"
><SPAN
CLASS="footnote"
>[4]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
><A
HREF="http://www.pathname.com/fhs/"
TARGET="_top"
>&#13;		http://www.pathname.com/fhs/</A
></P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x123.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="dir-tree-overview.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Important parts of the kernel</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c102.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Overview of the Directory Tree</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>