commit bcbf154bf083d0df2fb0293a129909117a2d35cf Author: Jaromir Hradilek jhradile@redhat.com Date: Sat Jun 12 01:29:21 2010 +0200
Removed all tabs.
Again, I have replaced all '\t' characters with two spaces to unite the indentation style.
en-US/Controlling_Access_to_Services.xml | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-) --- diff --git a/en-US/Controlling_Access_to_Services.xml b/en-US/Controlling_Access_to_Services.xml index b88d54f..02a268f 100644 --- a/en-US/Controlling_Access_to_Services.xml +++ b/en-US/Controlling_Access_to_Services.xml @@ -46,10 +46,10 @@ <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> + 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> + 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"> <title>Important</title> @@ -100,9 +100,9 @@ significance="normal"> <primary>TCP wrappers</primary> </indexterm> - Many UNIX system administrators are accustomed to using TCP wrappers to manage access to certain network services. Any network services managed by <command>xinetd</command> (as well as any program with built-in support for <command>libwrap</command>) can use TCP wrappers to manage access. <command>xinetd</command> can use the <filename>/etc/hosts.allow</filename> and <filename>/etc/hosts.deny</filename> files to configure access to system services. As the names imply, <filename>hosts.allow</filename> contains a list of rules that allow clients to access the network services controlled by <command>xinetd</command>, and <filename>hosts.deny</filename> contains rules to deny access. The <filename>hosts.allow</filename> file takes precedence over the <filename>hosts.deny</filename> file. Permissions to grant or deny access can be based on individual IP address (or hostnames) or on a pattern of clients. Refer to <filename>hosts_access</filename> in section 5 of the man pages (<command>man 5 hosts_access</command>) for details.</para> - <!-- RHEL5: REMOVING CROSS LINK - <para>For more information on using TCP Wrappers, refer to <xref linkend="s1-tcpwrappers-purpose"/>.</para> + Many UNIX system administrators are accustomed to using TCP wrappers to manage access to certain network services. Any network services managed by <command>xinetd</command> (as well as any program with built-in support for <command>libwrap</command>) can use TCP wrappers to manage access. <command>xinetd</command> can use the <filename>/etc/hosts.allow</filename> and <filename>/etc/hosts.deny</filename> files to configure access to system services. As the names imply, <filename>hosts.allow</filename> contains a list of rules that allow clients to access the network services controlled by <command>xinetd</command>, and <filename>hosts.deny</filename> contains rules to deny access. The <filename>hosts.allow</filename> file takes precedence over the <filename>hosts.deny</filename> file. Permissions to grant or deny access can be based on individual IP address (or hostnames) or on a pattern of clients. Refer to <filename>hosts_access</filename> in section 5 of the man pag es (<command>man 5 hosts_access</command>) for details.</para> + <!-- RHEL5: REMOVING CROSS LINK + <para>For more information on using TCP Wrappers, refer to <xref linkend="s1-tcpwrappers-purpose"/>.</para> --> <section id="s2-services-xinetd"> @@ -126,8 +126,8 @@ <para> <command>xinetd</command> runs constantly and listens on all ports for the services it manages. When a connection request arrives for one of its managed services, <command>xinetd</command> starts up the appropriate server for that service.</para> <para>The configuration file for <command>xinetd</command> is <filename>/etc/xinetd.conf</filename>, but the file only contains a few defaults and an instruction to include the <filename>/etc/xinetd.d</filename> directory. To enable or disable an <command>xinetd</command> service, edit its configuration file in the <filename>/etc/xinetd.d</filename> directory. If the <computeroutput>disable</computeroutput> attribute is set to <userinput>yes</userinput>, the service is disabled. If the <computeroutput>disable</computeroutput> attribute is set to <userinput>no</userinput>, the service is enabled. You can edit any of the <command>xinetd</command> configuration files or change its enabled status using the <application>Services Configuration Tool</application>, <application>ntsysv</application>, or <command>chkconfig</command>. For a list of network services controlled by <command>xinetd</command>, review the contents of the <filename>/etc/xinetd.d</filename> directory wit h the command <command>ls /etc/xinetd.d</command>.</para> - <!-- RHEL5: REMOVING CROSS LINK - <para>For more information on using <command>xinetd</command>, refer to <xref linkend="s1-tcpwrappers-xinetd"/>.</para> + <!-- RHEL5: REMOVING CROSS LINK + <para>For more information on using <command>xinetd</command>, refer to <xref linkend="s1-tcpwrappers-xinetd"/>.</para> --> </section> </section> @@ -203,7 +203,7 @@ </indexterm> <para>The <application>ntsysv</application> utility provides a simple interface for activating or deactivating services. You can use <application>ntsysv</application> to turn an <command>xinetd</command>-managed service on or off. You can also use <application>ntsysv</application> to configure runlevels. By default, only the current runlevel is configured. To configure a different runlevel, specify one or more runlevels with the <option>--level</option> option. For example, the command <command>ntsysv --level 345</command> configures runlevels 3, 4, and 5.</para> <para>The <application>ntsysv</application> interface works like the text mode installation program. Use the up and down arrows to navigate up and down the list. The space bar selects/unselects services and is also used to "press" the <guilabel>Ok</guilabel> and <guilabel>Cancel</guilabel> buttons. To move between the list of services and the <guilabel>Ok</guilabel> and <guilabel>Cancel</guilabel> buttons, use the <keycap>Tab</keycap> key. An asterisk (<guilabel>*</guilabel>) signifies that a service is set to on. Pressing the <keycap>F1</keycap> key displays a short description of the selected service.</para> - <!-- RHEL5: ddomingo@redhat.com: added PNG image --> + <!-- RHEL5: ddomingo@redhat.com: added PNG image --> <figure float="0" id="fig-ntsysv">
docs-commits@lists.fedoraproject.org