PERFORCE change 185496 for review
Rene Ladan
rene at FreeBSD.org
Sun Nov 7 23:06:41 UTC 2010
http://p4web.freebsd.org/@@185496?ac=10
Change 185496 by rene at rene_acer on 2010/11/07 23:06:31
Continue pre-7.X cleanup of Handbook:
- remove some 5.X distinctions
- add comments to text referring to "older versions" , unclear how old
- add a missing "Alpha" in the introduction
- remove section about KerberosIV (old 14.7), 5.X only runs Kerberos5
- remove first paragraph of new section 14.7 (Kerberos5)
- mail/sylpheed-claws port got renamed (see /usr/ports/MOVED)
Affected files ...
.. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/boot/chapter.sgml#7 edit
.. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/config/chapter.sgml#12 edit
.. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml#17 edit
.. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/security/chapter.sgml#14 edit
Differences ...
==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/boot/chapter.sgml#7 (text+ko) ====
@@ -788,9 +788,6 @@
</indexterm>
<title>Device Hints</title>
- <note><para>This is a FreeBSD 5.0 and later feature which does not
- exist in earlier versions.</para></note>
-
<para>During initial system startup, the boot &man.loader.8; will read the
&man.device.hints.5; file. This file stores kernel boot information
known as variables, sometimes referred to as <quote>device hints</quote>.
==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/config/chapter.sgml#12 (text+ko) ====
@@ -897,8 +897,8 @@
those involved with &os;, have taken the latter
approach.</para>
- <para>Thanks to the contributions of Bill Paul (wpaul), as of
- &os; 5.3-RELEASE there is <quote>native</quote> support
+ <para>Thanks to the contributions of Bill Paul (wpaul)
+ there is <quote>native</quote> support
for the Network Driver Interface Specification (NDIS). The
&os; NDISulator (otherwise known as Project Evil) takes a
&windows; driver binary and basically tricks it into
@@ -1901,9 +1901,9 @@
reduce system boot times. The defaults are fairly high and can be
responsible for <literal>15</literal> seconds of delay in the
boot process. Reducing it to <literal>5</literal> seconds usually
- works (especially with modern drives). Newer versions of &os;
- (5.0 and higher) should use the <varname>kern.cam.scsi_delay</varname>
- boot time tunable. The tunable, and kernel config option accept
+ works (especially with modern drives).
+ The <varname>kern.cam.scsi_delay</varname> boot time tunable should
+ be used. The tunable, and kernel config option accept
values in terms of <emphasis>milliseconds</emphasis> and
<emphasis>not</emphasis> <emphasis>seconds</emphasis>.</para>
</sect3>
@@ -2124,7 +2124,7 @@
<para>In older FreeBSD releases, the default value of <varname>kern.maxfiles</varname>
is derived from the <option>maxusers</option> option in your
- kernel configuration file. <varname>kern.maxfiles</varname> grows
+ kernel configuration file. <!--rene last sentence still relevant?--> <varname>kern.maxfiles</varname> grows
proportionally to the value of <option>maxusers</option>. When
compiling a custom kernel, it is a good idea to set this kernel
configuration option according to the uses of your system. From
@@ -2148,7 +2148,7 @@
<filename>/boot/defaults/loader.conf</filename> file for some hints)
or as described elsewhere in this document.</para>
- <para>In older releases, the system will auto-tune
+ <para>In older releases, <!--rene how old?-->the system will auto-tune
<literal>maxusers</literal> for you if you explicitly set it to
<literal>0</literal><footnote>
<para>The auto-tuning algorithm sets
@@ -2228,7 +2228,7 @@
use.</para>
<para><varname>kern.ipc.nmbclusters</varname> loader tunable should
- be used to tune this at boot time. Only older versions of &os;
+ be used to tune this at boot time. Only older versions of &os;<!--rene: how old?-->
will require you to use the <literal>NMBCLUSTERS</literal> kernel
&man.config.8; option.</para>
==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml#17 (text+ko) ====
@@ -651,7 +651,7 @@
November 2005. The most recent 6.4-RELEASE came out in
November 2008. There will be no additional releases from the
RELENG_6 branch. This branch is the last branch to support the
- architecture.</para>
+ Alpha architecture.</para>
<para>The RELENG_7 branch was created in October 2007. The first
release of this branch was 7.0-RELEASE, which came
==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/security/chapter.sgml#14 (text+ko) ====
@@ -56,11 +56,6 @@
</listitem>
<listitem>
- <para>How to set up <application>KerberosIV</application> on &os;
- releases prior to 5.0.</para>
- </listitem>
-
- <listitem>
<para>How to set up <application>Kerberos5</application> on
&os;.</para>
</listitem>
@@ -407,7 +402,6 @@
vast majority of break-ins occur remotely, over a network, from
people who do not have physical access to your workstation or
servers.</para>
- <indexterm><primary>KerberosIV</primary></indexterm>
<para>Using something like Kerberos also gives you the ability to
disable or change the password for a staff account in one place,
@@ -944,7 +938,6 @@
<sect2>
<title>Access Issues with Kerberos and SSH</title>
<indexterm><primary><command>ssh</command></primary></indexterm>
- <indexterm><primary>KerberosIV</primary></indexterm>
<para>There are a few issues with both Kerberos and
ssh that need to be addressed if
@@ -1565,496 +1558,6 @@
</sect2>
</sect1>
- <sect1 id="kerberosIV">
- <sect1info>
- <authorgroup>
- <author>
- <firstname>Mark</firstname>
- <surname>Murray</surname>
- <contrib>Contributed by </contrib>
- </author>
- </authorgroup>
- <authorgroup>
- <author>
- <firstname>Mark</firstname>
- <surname>Dapoz</surname>
- <contrib>Based on a contribution by </contrib>
- </author>
- </authorgroup>
- </sect1info>
-
- <title><application>KerberosIV</application></title>
-
- <para>Kerberos is a network add-on system/protocol that allows users to
- authenticate themselves through the services of a secure server.
- Services such as remote login, remote copy, secure inter-system file
- copying and other high-risk tasks are made considerably safer and more
- controllable.</para>
-
- <para>The following instructions can be used as a guide on how to set up
- Kerberos as distributed for &os;. However, you should refer to the
- relevant manual pages for a complete description.</para>
-
- <sect2>
- <title>Installing <application>KerberosIV</application></title>
-
- <indexterm><primary>MIT</primary></indexterm>
- <indexterm>
- <primary>KerberosIV</primary>
- <secondary>installing</secondary>
- </indexterm>
- <para>Kerberos is an optional component of &os;. The easiest
- way to install this software is by selecting the <literal>krb4</literal> or
- <literal>krb5</literal> distribution in <application>sysinstall</application>
- during the initial installation of &os;. This will install
- the <quote>eBones</quote> (KerberosIV) or <quote>Heimdal</quote> (Kerberos5)
- implementation of Kerberos. These implementations are
- included because they are developed outside the USA/Canada and
- were thus available to system owners outside those countries
- during the era of restrictive export controls on cryptographic
- code from the USA.</para>
-
- <para>Alternatively, the MIT implementation of Kerberos is
- available from the Ports Collection as
- <filename role="package">security/krb5</filename>.</para>
- </sect2>
-
- <sect2>
- <title>Creating the Initial Database</title>
-
- <para>This is done on the Kerberos server only. First make sure that
- you do not have any old Kerberos databases around. You should change
- to the directory <filename class="directory">/etc/kerberosIV</filename>
- and check that only the following files are present:</para>
-
- <screen>&prompt.root; <userinput>cd /etc/kerberosIV</userinput>
-&prompt.root; <userinput>ls</userinput>
-README krb.conf krb.realms</screen>
-
- <para>If any additional files (such as <filename>principal.*</filename>
- or <filename>master_key</filename>) exist, then use the
- <command>kdb_destroy</command> command to destroy the old Kerberos
- database, or if Kerberos is not running, simply delete the extra
- files.</para>
-
- <para>You should now edit the <filename>krb.conf</filename> and
- <filename>krb.realms</filename> files to define your Kerberos realm.
- In this case the realm will be <literal>EXAMPLE.COM</literal> and the
- server is <hostid role="fqdn">grunt.example.com</hostid>. We edit
- or create the <filename>krb.conf</filename> file:</para>
-
- <screen>&prompt.root; <userinput>cat krb.conf</userinput>
-EXAMPLE.COM
-EXAMPLE.COM grunt.example.com admin server
-CS.BERKELEY.EDU okeeffe.berkeley.edu
-ATHENA.MIT.EDU kerberos.mit.edu
-ATHENA.MIT.EDU kerberos-1.mit.edu
-ATHENA.MIT.EDU kerberos-2.mit.edu
-ATHENA.MIT.EDU kerberos-3.mit.edu
-LCS.MIT.EDU kerberos.lcs.mit.edu
-TELECOM.MIT.EDU bitsy.mit.edu
-ARC.NASA.GOV trident.arc.nasa.gov</screen>
-
- <para>In this case, the other realms do not need to be there. They are
- here as an example of how a machine may be made aware of multiple
- realms. You may wish to not include them for simplicity.</para>
-
- <para>The first line names the realm in which this system works. The
- other lines contain realm/host entries. The first item on a line is a
- realm, and the second is a host in that realm that is acting as a
- <quote>key distribution center</quote>. The words <literal>admin
- server</literal> following a host's name means that host also
- provides an administrative database server. For further explanation
- of these terms, please consult the Kerberos manual pages.</para>
-
- <para>Now we have to add <hostid role="fqdn">grunt.example.com</hostid>
- to the <literal>EXAMPLE.COM</literal> realm and also add an entry to
- put all hosts in the <hostid role="domainname">.example.com</hostid>
- domain in the <literal>EXAMPLE.COM</literal> realm. The
- <filename>krb.realms</filename> file would be updated as
- follows:</para>
-
- <screen>&prompt.root; <userinput>cat krb.realms</userinput>
-grunt.example.com EXAMPLE.COM
-.example.com EXAMPLE.COM
-.berkeley.edu CS.BERKELEY.EDU
-.MIT.EDU ATHENA.MIT.EDU
-.mit.edu ATHENA.MIT.EDU</screen>
-
- <para>Again, the other realms do not need to be there. They are here as
- an example of how a machine may be made aware of multiple realms. You
- may wish to remove them to simplify things.</para>
-
- <para>The first line puts the <emphasis>specific</emphasis> system into
- the named realm. The rest of the lines show how to default systems of
- a particular subdomain to a named realm.</para>
-
- <para>Now we are ready to create the database. This only needs to run
- on the Kerberos server (or Key Distribution Center). Issue the
- <command>kdb_init</command> command to do this:</para>
-
- <screen>&prompt.root; <userinput>kdb_init</userinput>
-<prompt>Realm name [default ATHENA.MIT.EDU ]:</prompt> <userinput>EXAMPLE.COM</userinput>
-You will be prompted for the database Master Password.
-It is important that you NOT FORGET this password.
-
-<prompt>Enter Kerberos master key:</prompt> </screen>
-
- <para>Now we have to save the key so that servers on the local machine
- can pick it up. Use the <command>kstash</command> command to do
- this:</para>
-
- <screen>&prompt.root; <userinput>kstash</userinput>
-
-<prompt>Enter Kerberos master key:</prompt>
-
-Current Kerberos master key version is 1.
-
-Master key entered. BEWARE!</screen>
-
- <para>This saves the encrypted master password in
- <filename>/etc/kerberosIV/master_key</filename>.</para>
- </sect2>
-
- <sect2>
- <title>Making It All Run</title>
-
- <indexterm>
- <primary>KerberosIV</primary>
- <secondary>initial startup</secondary>
- </indexterm>
-
- <para>Two principals need to be added to the database for
- <emphasis>each</emphasis> system that will be secured with Kerberos.
- Their names are <literal>kpasswd</literal> and <literal>rcmd</literal>.
- These two principals are made for each system, with the instance being
- the name of the individual system.</para>
-
- <para>These daemons, <application>kpasswd</application> and
- <application>rcmd</application> allow other systems to change Kerberos
- passwords and run commands like &man.rcp.1;,
- &man.rlogin.1; and &man.rsh.1;.</para>
-
- <para>Now let us add these entries:</para>
-
- <screen>&prompt.root; <userinput>kdb_edit</userinput>
-Opening database...
-
-<prompt>Enter Kerberos master key:</prompt>
-
-Current Kerberos master key version is 1.
-
-Master key entered. BEWARE!
-Previous or default values are in [brackets] ,
-enter return to leave the same, or new value.
-
-<prompt>Principal name:</prompt> <userinput>passwd</userinput>
-<prompt>Instance:</prompt> <userinput>grunt</userinput>
-
-<Not found>, <prompt>Create [y] ?</prompt> <userinput>y</userinput>
-
-Principal: passwd, Instance: grunt, kdc_key_ver: 1
-<prompt>New Password:</prompt> <---- enter RANDOM here
-Verifying password
-
-<prompt>New Password:</prompt> <---- enter RANDOM here
-
-<prompt>Random password [y] ?</prompt> <userinput>y</userinput>
-
-Principal's new key version = 1
-<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
-<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt>
-<prompt>Attributes [ 0 ] ?</prompt>
-Edit O.K.
-<prompt>Principal name:</prompt> <userinput>rcmd</userinput>
-<prompt>Instance:</prompt> <userinput>grunt</userinput>
-
-<Not found>, <prompt>Create [y] ?</prompt>
-
-Principal: rcmd, Instance: grunt, kdc_key_ver: 1
-<prompt>New Password:</prompt> <---- enter RANDOM here
-Verifying password
-
-<prompt>New Password:</prompt> <---- enter RANDOM here
-
-<prompt>Random password [y] ?</prompt>
-
-Principal's new key version = 1
-<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
-<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt>
-<prompt>Attributes [ 0 ] ?</prompt>
-Edit O.K.
-<prompt>Principal name:</prompt> <---- null entry here will cause an exit</screen>
- </sect2>
-
- <sect2>
- <title>Creating the Server File</title>
-
- <para>We now have to extract all the instances which define the
- services on each machine. For this we use the
- <command>ext_srvtab</command> command. This will create a file
- which must be copied or moved <emphasis>by secure means</emphasis> to
- each Kerberos client's <filename class="directory">/etc</filename>
- directory. This file must be present on each server and client, and is
- crucial to the operation of Kerberos.</para>
-
-
- <screen>&prompt.root; <userinput>ext_srvtab grunt</userinput>
-<prompt>Enter Kerberos master key:</prompt>
-
-Current Kerberos master key version is 1.
-
-Master key entered. BEWARE!
-Generating 'grunt-new-srvtab'....</screen>
-
- <para>Now, this command only generates a temporary file which must be
- renamed to <filename>srvtab</filename> so that all the servers can pick
- it up. Use the &man.mv.1; command to move it into place on
- the original system:</para>
-
- <screen>&prompt.root; <userinput>mv grunt-new-srvtab srvtab</userinput></screen>
-
- <para>If the file is for a client system, and the network is not deemed
- safe, then copy the
- <filename><replaceable>client</replaceable>-new-srvtab</filename> to
- removable media and transport it by secure physical means. Be sure to
- rename it to <filename>srvtab</filename> in the client's <filename
- class="directory">/etc</filename> directory, and make sure it is
- mode 600:</para>
-
- <screen>&prompt.root; <userinput>mv grumble-new-srvtab srvtab</userinput>
-&prompt.root; <userinput>chmod 600 srvtab</userinput></screen>
- </sect2>
-
- <sect2>
- <title>Populating the Database</title>
-
- <para>We now have to add some user entries into the database. First
- let us create an entry for the user <username>jane</username>. Use the
- <command>kdb_edit</command> command to do this:</para>
-
- <screen>&prompt.root; <userinput>kdb_edit</userinput>
-Opening database...
-
-<prompt>Enter Kerberos master key:</prompt>
-
-Current Kerberos master key version is 1.
-
-Master key entered. BEWARE!
-Previous or default values are in [brackets] ,
-enter return to leave the same, or new value.
-
-<prompt>Principal name:</prompt> <userinput>jane</userinput>
-<prompt>Instance:</prompt>
-
-<Not found>, <prompt>Create [y] ?</prompt> <userinput>y</userinput>
-
-Principal: jane, Instance: , kdc_key_ver: 1
-<prompt>New Password:</prompt> <---- enter a secure password here
-Verifying password
-
-<prompt>New Password:</prompt> <---- re-enter the password here
-Principal's new key version = 1
-<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
-<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt>
-<prompt>Attributes [ 0 ] ?</prompt>
-Edit O.K.
-<prompt>Principal name:</prompt> <---- null entry here will cause an exit</screen>
- </sect2>
-
- <sect2>
- <title>Testing It All Out</title>
-
- <para>First we have to start the Kerberos daemons. Note that if you
- have correctly edited your <filename>/etc/rc.conf</filename> then this
- will happen automatically when you reboot. This is only necessary on
- the Kerberos server. Kerberos clients will automatically get what
- they need from the <filename
- class="directory">/etc/kerberosIV</filename> directory.</para>
-
- <screen>&prompt.root; <userinput>kerberos &</userinput>
-Kerberos server starting
-Sleep forever on error
-Log file is /var/log/kerberos.log
-Current Kerberos master key version is 1.
-
-Master key entered. BEWARE!
-
-Current Kerberos master key version is 1
-Local realm: EXAMPLE.COM
-&prompt.root; <userinput>kadmind -n &</userinput>
-KADM Server KADM0.0A initializing
-Please do not use 'kill -9' to kill this job, use a
-regular kill instead
-
-Current Kerberos master key version is 1.
-
-Master key entered. BEWARE!</screen>
-
- <para>Now we can try using the <command>kinit</command> command to get a
- ticket for the ID <username>jane</username> that we created
- above:</para>
-
- <screen>&prompt.user; <userinput>kinit jane</userinput>
-MIT Project Athena (grunt.example.com)
-Kerberos Initialization for "jane"
-<prompt>Password:</prompt> </screen>
-
- <para>Try listing the tokens using <command>klist</command> to see if we
- really have them:</para>
-
- <screen>&prompt.user; <userinput>klist</userinput>
-Ticket file: /tmp/tkt245
-Principal: jane at EXAMPLE.COM
-
- Issued Expires Principal
-Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM at EXAMPLE.COM</screen>
-
- <para>Now try changing the password using &man.passwd.1; to
- check if the <application>kpasswd</application> daemon can get
- authorization to the Kerberos database:</para>
-
- <screen>&prompt.user; <userinput>passwd</userinput>
-realm EXAMPLE.COM
-<prompt>Old password for jane:</prompt>
-<prompt>New Password for jane:</prompt>
-Verifying password
-<prompt>New Password for jane:</prompt>
-Password changed.</screen>
- </sect2>
-
- <sect2>
- <title>Adding <command>su</command> Privileges</title>
-
- <para>Kerberos allows us to give <emphasis>each</emphasis> user
- who needs <username>root</username> privileges their own
- <emphasis>separate</emphasis> &man.su.1; password.
- We could now add an ID which is authorized to
- &man.su.1; to <username>root</username>. This is
- controlled by having an instance of <username>root</username>
- associated with a principal. Using <command>kdb_edit</command>
- we can create the entry <literal>jane.root</literal> in the
- Kerberos database:</para>
-
- <screen>&prompt.root; <userinput>kdb_edit</userinput>
-Opening database...
-
-<prompt>Enter Kerberos master key:</prompt>
-
-Current Kerberos master key version is 1.
-
-Master key entered. BEWARE!
-Previous or default values are in [brackets] ,
-enter return to leave the same, or new value.
-
-<prompt>Principal name:</prompt> <userinput>jane</userinput>
-<prompt>Instance:</prompt> <userinput>root</userinput>
-
-<Not found>, Create [y] ? y
-
-Principal: jane, Instance: root, kdc_key_ver: 1
-<prompt>New Password:</prompt> <---- enter a SECURE password here
-Verifying password
-
-<prompt>New Password:</prompt> <---- re-enter the password here
-
-Principal's new key version = 1
-<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
-<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt> <userinput>12</userinput> <--- Keep this short!
-<prompt>Attributes [ 0 ] ?</prompt>
-Edit O.K.
-<prompt>Principal name:</prompt> <---- null entry here will cause an exit</screen>
-
- <para>Now try getting tokens for it to make sure it works:</para>
-
- <screen>&prompt.root; <userinput>kinit jane.root</userinput>
-MIT Project Athena (grunt.example.com)
-Kerberos Initialization for "jane.root"
-<prompt>Password:</prompt></screen>
-
- <para>Now we need to add the user to <username>root</username>'s
- <filename>.klogin</filename> file:</para>
-
- <screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
-jane.root at EXAMPLE.COM</screen>
-
- <para>Now try doing the &man.su.1;:</para>
-
- <screen>&prompt.user; <userinput>su</userinput>
-<prompt>Password:</prompt></screen>
-
- <para>and take a look at what tokens we have:</para>
-
- <screen>&prompt.root; <userinput>klist</userinput>
-Ticket file: /tmp/tkt_root_245
-Principal: jane.root at EXAMPLE.COM
-
- Issued Expires Principal
-May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM at EXAMPLE.COM</screen>
- </sect2>
-
- <sect2>
- <title>Using Other Commands</title>
-
- <para>In an earlier example, we created a principal called
- <literal>jane</literal> with an instance <literal>root</literal>.
- This was based on a user with the same name as the principal, and this
- is a Kerberos default; that a
- <literal><principal>.<instance></literal> of the form
- <literal><username>.</literal><username>root</username> will allow
- that <literal><username></literal> to &man.su.1; to
- <username>root</username> if the necessary entries are in the
- <filename>.klogin</filename> file in <username>root</username>'s
- home directory:</para>
-
- <screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
-jane.root at EXAMPLE.COM</screen>
-
- <para>Likewise, if a user has in their own home directory lines of the
- form:</para>
-
- <screen>&prompt.user; <userinput>cat ~/.klogin</userinput>
-jane at EXAMPLE.COM
-jack at EXAMPLE.COM</screen>
-
- <para>This allows anyone in the <literal>EXAMPLE.COM</literal> realm
- who has authenticated themselves as <username>jane</username> or
- <username>jack</username> (via <command>kinit</command>, see above)
- to access to <username>jane</username>'s
- account or files on this system (<hostid>grunt</hostid>) via
- &man.rlogin.1;, &man.rsh.1; or
- &man.rcp.1;.</para>
-
- <para>For example, <username>jane</username> now logs into another system using
- Kerberos:</para>
-
- <screen>&prompt.user; <userinput>kinit</userinput>
-MIT Project Athena (grunt.example.com)
-<prompt>Password:</prompt>
-&prompt.user; <userinput>rlogin grunt</userinput>
-Last login: Mon May 1 21:14:47 from grumble
-Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
- The Regents of the University of California. All rights reserved.
-
-FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
-
- <para>Or <username>jack</username> logs into <username>jane</username>'s account on the same machine
- (<username>jane</username> having
- set up the <filename>.klogin</filename> file as above, and the person
- in charge of Kerberos having set up principal
- <emphasis>jack</emphasis> with a null instance):</para>
-
- <screen>&prompt.user; <userinput>kinit</userinput>
-&prompt.user; <userinput>rlogin grunt -l jane</userinput>
-MIT Project Athena (grunt.example.com)
-<prompt>Password:</prompt>
-Last login: Mon May 1 21:16:55 from grumble
-Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
- The Regents of the University of California. All rights reserved.
-FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
- </sect2>
- </sect1>
-
<sect1 id="kerberos5">
<sect1info>
<authorgroup>
@@ -2075,17 +1578,6 @@
<title><application>Kerberos5</application></title>
- <para>Every &os; release beyond &os;-5.1 includes support
- only for <application>Kerberos5</application>. Hence
- <application>Kerberos5</application> is the only version
- included, and its configuration is similar in many aspects
- to that of <application>KerberosIV</application>. The following
- information only applies to
- <application>Kerberos5</application> in post &os;-5.0
- releases. Users who wish to use the
- <application>KerberosIV</application> package may install the
- <filename role="package">security/krb4</filename> port.</para>
-
<para><application>Kerberos</application> is a network add-on
system/protocol that allows users to authenticate themselves
through the services of a secure server. Services such as remote
@@ -2860,7 +2352,7 @@
encrypted authentication of mail clients, web based transactions
such as credit card payments and more. Many ports such as
<filename role="package">www/apache13-ssl</filename>, and
- <filename role="package">mail/sylpheed-claws</filename>
+ <filename role="package">mail/claws-mail</filename>
will offer compilation support for building with
<application>OpenSSL</application>.</para>
@@ -3981,8 +3473,8 @@
</indexterm>
<title>File System Access Control Lists</title>
- <para>In conjunction with file system enhancements like snapshots, FreeBSD 5.0
- and later offers the security of File System Access Control Lists
+ <para>In conjunction with file system enhancements like snapshots, FreeBSD
+ offers the security of File System Access Control Lists
(<acronym>ACL</acronym>s).</para>
<para>Access Control Lists extend the standard &unix;
More information about the p4-projects
mailing list