Add SHARES and USER AUTHORIZATION sections.
[doldaconnect.git] / doc / doldacond.8
index 313be4e..c583f2f 100644 (file)
@@ -27,7 +27,7 @@ doldacond \- Dolda Connect daemon
 .SH SYNOPSIS
 .B doldacond
 [ \fB-hns\fP ] [ \fB-C\fP \fIconfigfile\fP ]
-[ \fB-p\fP \fIpidfile\fP ] [ \fB-f\fP -fIfacility\fP ]
+[ \fB-p\fP \fIpidfile\fP ] [ \fB-f\fP \fIfacility\fP ]
 .SH DESCRIPTION
 The \fBdoldacond\fP program is the primary part of the collection of
 software that makes up Dolda Connect. It runs in the background and
@@ -96,15 +96,17 @@ Dolda Connect, including \fBdoldacond\fP and its assorted clients, are
 capable of a number of different authentication methods. The default
 configuration will cause the daemon to only listen for client
 connections on a Unix socket, over which authentication will be made
-using Unix credentials passing. When running clients over a network,
-authentication can be done using either PAM, Kerberos 5 (requires the
-MIT libraries) or client trust (no authentication). Unix credentials
-passing and Kerberos authentication should be perfectly secure. PAM
-authentication should be secure in itself, but the client protocol is
-not encrypted, and therefore causes passwords to be sent over the
-network in the clear. Authentication-less operation is, obviously, not
-secure at all and is disabled by default. It may be useful on a
-trusted network, however.
+using Unix credentials passing.
+.P
+When running clients over a network, authentication can be done using
+either PAM, Kerberos 5 (requires the MIT libraries) or client trust
+(no authentication). Unix credentials passing and Kerberos
+authentication should be perfectly secure. PAM authentication should
+be secure in itself, but the client protocol is not encrypted, and
+therefore causes passwords to be sent over the network in the
+clear. Authentication-less operation is, obviously, not secure at all
+and is disabled by default. It may be useful on a trusted network,
+however.
 .SH BUGS
 \fBdoldacond\fP has proved to be surprisingly stable. I have had it
 running for far longer than a month without any sign of instability or
@@ -121,9 +123,9 @@ indexing by i-numbers rather than file names allows the daemon to not
 rehash files that have merely been renamed. However, among the
 filesystems that do not have persistent i-numbers is the Linux
 implementation of FAT, which means that it is impossible to share
-files that are shared with Microsoft Windows. All the known standard
-Unix filesystems, including at least ufs, ext2/3, reiserfs, xfs or any
-of them shared over nfs are known to be safe.
+files that are shared with Microsoft Windows. All the standard Unix
+filesystems, including at least ufs, ext2/3, reiserfs, xfs or any of
+them shared over nfs are known to be safe.
 .P
 From time to time, the hash controller can get stuck, and stop
 processing more files. The obvious work-around is to restart