[deployment-guide/comm-rel: 14/26] Simplified the chapter introduction.

[dsilas]

commit e68c8b9238a80f6b8429394c1bf01b95fd31662c
Author: Jaromir Hradilek <jhradile at redhat.com>
Date:   Wed Jun 16 16:34:38 2010 +0200

    Simplified the chapter introduction.
    
    I have removed a lot of unnecessary information as I covered it in the
    rest of the chapter.

 en-US/Controlling_Access_to_Services.xml |   47 ++++-------------------------
 1 files changed, 7 insertions(+), 40 deletions(-)
---
diff --git a/en-US/Controlling_Access_to_Services.xml b/en-US/Controlling_Access_to_Services.xml
index a38edea..55c868e 100644
--- a/en-US/Controlling_Access_to_Services.xml
+++ b/en-US/Controlling_Access_to_Services.xml
@@ -3,47 +3,14 @@
 ]>
 <chapter id="ch-Controlling_Access_to_Services">
   <title>Controlling Access to Services</title>
-  <para>Maintaining security on your system is extremely important, and one approach for this task is to manage access to system services carefully. Your system may need to provide open access to particular services (for example, <command>httpd</command> if you are running a Web server). However, if you do not need to provide a service, you should turn it off to minimize your exposure to possible bug exploits.</para>
-  <para>There are several different methods for managing access to system services. <!-- RHEL5:  Decide  -->Choose which method of management to use based on the service, your system's configuration, and your level of Linux expertise.</para>
-  <para>The easiest way to deny access to a service is to turn it off. Both the services managed by <command>xinetd</command> and the services in the <filename>/etc/rc.d/init.d</filename> hierarchy (also known as SysV services) can be configured to start or stop using three different applications:</para>
-  <variablelist>
-    <varlistentry>
-      <term>
-        <application>Services Configuration Tool </application>
-      </term>
-      <listitem>
-        <para>This is a graphical application that displays a description of each service, displays whether each service is started at boot time (for runlevels 3, 4, and 5), and allows services to be started, stopped, and restarted.</para>
-      </listitem>
-    </varlistentry>
-    <varlistentry>
-      <term>
-        <application>ntsysv</application>
-      </term>
-      <listitem>
-        <para>This is a text-based application that allows you to configure which services are started at boot time for each runlevel. Non-<command>xinetd</command> services can not be started, stopped, or restarted using this program.</para>
-      </listitem>
-    </varlistentry>
-    <varlistentry>
-      <term>
-        <command>chkconfig</command>
-      </term>
-      <listitem>
-        <para>This is a command line utility that allows you to turn services on and off for the different runlevels. Non-<command>xinetd</command> services can not be started, stopped, or restarted using this utility.</para>
-      </listitem>
-    </varlistentry>
-  </variablelist>
-  <para>You may find that these tools are easier to use than the alternatives — editing the numerous symbolic links located in the directories below <filename>/etc/rc.d</filename> by hand or editing the <command>xinetd</command> configuration files in <filename>/etc/xinetd.d</filename>.</para>
-  <para>Another way to manage access to system services is by using <command>iptables</command> to configure an IP firewall. If you are a new Linux user, <!-- RHEL5:  please realize  -->note that <command>iptables</command> may not be the best solution for you. Setting up <command>iptables</command> can be complicated, and is best tackled by experienced Linux system administrators.</para>
-  <para
-    lang="en-US,as-IN,bn-IN,gu-IN,hi-IN,kn-IN,ml-IN,mr-IN,or-IN,pa-IN,si-LK,ta-IN,te-IN">
-    On the other hand, the benefit of using <command>iptables</command> is flexibility. For example, if you need a customized solution which provides certain hosts access to certain services, <command>iptables</command> can provide it for you. Refer to <!-- TBD6: <xref linkend="s1-firewall-ipt"/> --> and <!-- TBD6: <xref linkend="s1-fireall-ipt-act"/> --> for more information about <command>iptables</command>.</para>
-  <para
-    lang="en-US,as-IN,bn-IN,gu-IN,hi-IN,kn-IN,ml-IN,mr-IN,or-IN,pa-IN,si-LK,ta-IN,te-IN">
-    Refer to <!-- TBD6: <xref linkend="ch-fw"/> --> for more information.</para>
-  <important
-    lang="en-US,as-IN,bn-IN,gu-IN,hi-IN,kn-IN,ml-IN,mr-IN,or-IN,pa-IN,si-LK,ta-IN,te-IN">
+  <para>
+    Maintaining security on your system is extremely important, and one approach for this task is to manage access to system services carefully. Your system may need to provide open access to particular services (for example, <command>httpd</command> if you are running a web server). However, if you do not need to provide a service, you should turn it off to minimize your exposure to possible bug exploits.
+  </para>
+  <important lang="en-US,as-IN,bn-IN,gu-IN,hi-IN,kn-IN,ml-IN,mr-IN,or-IN,pa-IN,si-LK,ta-IN,te-IN">
     <title>Important</title>
-    <para>When you allow access for new services, always remember that both the firewall and SELinux need to be configured as well. One of the most common mistakes committed when configuring a new service is neglecting to implement the necessary firewall configuration and SELinux policies to allow access for it. Refer to <!-- TBD6: <xref linkend="s1-basic-firewall"/> --> for more information.</para>
+    <para>
+      When you allow access for new services, always remember that both the firewall and <application>SELinux</application> need to be configured as well. One of the most common mistakes committed when configuring a new service is neglecting to implement the necessary firewall configuration and SELinux policies to allow access for it. Refer to <citetitle pubwork="book">Security Guide: A Guide to Securing Red Hat Enterprise Linux</citetitle> for more information.
+    </para>
   </important>
   <section id="s1-services-runlevels">
     <title>Configuring the Default Runlevel</title>