File: major-services.html

package info (click to toggle)
sysadmin-guide 0.9-1
links: PTS
area: main
in suites: jessie, jessie-kfreebsd, lenny, squeeze, wheezy
size: 944 kB
ctags: 1
sloc: makefile: 5
file content (785 lines) | stat: -rw-r--r-- 16,871 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<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="Linux System Administrators Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="Overview of a Linux System"
HREF="overview.html"><LINK
REL="PREVIOUS"
TITLE="Important parts of the kernel"
HREF="kernel-parts.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"
>Linux System Administrators Guide: </TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="kernel-parts.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 2. 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="MAJOR-SERVICES"
></A
>2.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="INIT"
></A
>2.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 ``system
	halt''.  Runlevel 1 is defined as ``single user mode''.  Runlevel 3 
	 is defined as
	"multi user" because it is the runlevel that the system boot into
	under normal day to day conditions.  Runlevel 5 is typically the same as 3 except that a GUI 
	 
	gets started also.
	Runlevel 6 is defined as ``system 
	reboot''.  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="TERMINAL-LOGINS"
></A
>2.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="SYSLOG"
></A
>2.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
><P
><A
HREF="system-logs.html"
>Chapter 15</A
> will provide more on
	 this.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CRON"
></A
>2.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
>We will go more into this later. See the manual pages 
	cron(1), crontab(1), crontab(5), at(1) and atd(8) for more in 
	depth information.</P
><P
><A
HREF="task-automation.html"
>Chapter 13</A
> will cover this.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="GUI"
></A
>2.3.5. Graphical user interface</H2
><P
>&#13;	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="NETWORKING"
></A
>2.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"
>	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="NETWORK-LOGINS"
></A
>2.3.7. Network logins</H2
><P
>Network logins work a little differently 
	than normal logins.  For each person logging in via the network
	there is a separate virtual network connection, 
	and there can be any number of these depending on the available 
	bandwidth.  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"
>ssh</B
>
	 being
	the major ones in TCP/IP networks.</P
><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 ``secure shell'', 
	which encrypts traffic going over the network, thereby making it far 
	less likely that the malicious can ``sniff'' 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
><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"
>ssh</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="NFS"
></A
>2.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
>.  Depending on your network this could 
	be done over the Network File System (NFS), or over 
	the Common Internet File System (CIFS).
	NFS is typically a 'UNIX' based service.  In Linux, NFS is supported
	by the kernel.  CIFS however is not.  In Linux,
	CIFS is supported by Samba <A
HREF="http://www.samba.org"
TARGET="_top"
>	http://www.samba.org</A
>.

	</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
>This will be covered in more detail in 
	<A
HREF="net-attached.html"
>Section 5.4</A
>.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="MAIL"
></A
>2.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"
>postfix</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
>
	, or 
	<B
CLASS="COMMAND"
>evolution</B
>
	.	
	The mailboxes are usually stored
	in <TT
CLASS="FILENAME"
>/var/spool/mail</TT
> until the user's MUA
	retrieves them.</P
><P
>For more information on setting up and running mail services
	you can read the Mail Administrator HOWTO at
	<A
HREF="http://www.tldp.org/HOWTO/Mail-Administrator-HOWTO.html"
TARGET="_top"
>	http://www.tldp.org/HOWTO/Mail-Administrator-HOWTO.html</A
>, or 
	visit the sendmail or postfix's website.
	<A
HREF="http://www.sendmail.org/"
TARGET="_top"
>http://www.sendmail.org/</A
>, 
	or <A
HREF="http://www.postfix.org/"
TARGET="_top"
>http://www.postfix.org/
	</A
>.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PRINTING"
></A
>2.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.
	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
><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
><P
>You can refer to the Printing-HOWTO located at
	<A
HREF="http://www.tldp.org/HOWTO/Printing-HOWTO/index.html"
TARGET="_top"
>	http://www.tldp.org/HOWTO/Printing-HOWTO/index.html</A
> 
	for more help in setting up printers.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="FS-LAYOUT"
></A
>2.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;
	<TT
CLASS="FILENAME"
>/var</TT
>
	 filesystem with changing
	data (such as log files); and a
	<TT
CLASS="FILENAME"
>/home</TT
>
	 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 3</A
> describes the filesystem
	layout in some little detail; the Filesystem Hierarchy Standard
	. covers 
	it in somewhat more detail.  This can be found on the web at:
	<A
HREF="http://www.pathname.com/fhs/"
TARGET="_top"
>	http://www.pathname.com/fhs/</A
></P
></DIV
></DIV
><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="kernel-parts.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="overview.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Overview of the Directory Tree</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>