diff --git a/documentation/documentation/fsconfigref.page b/documentation/documentation/fsconfigref.page
index 598676184..dca390cd8 100644
--- a/documentation/documentation/fsconfigref.page
+++ b/documentation/documentation/fsconfigref.page
@@ -1,106 +1,106 @@
 ---
 inMenu: true
 title: Fileserver Reference
 orderInfo: 8
 ---
 
 # FileServer
 
 Puppet comes with both a client and server for copying files around.  The file
 serving function is provided as part of the central Puppet daemon,
 ``puppetmasterd``, and the client function is used through the ``source``
 attribute of ``file`` objects:
 
-    # copy a remove file to /etc/sudoers
+    # copy a remote file to /etc/sudoers
     file { "/etc/sudoers":
         mode => 440,
         owner => root,
         group => root,
         source => "puppet://server/module/sudoers"
     }
 
 As the example implies, Puppet's fileserving function abstracts local
 filesystem topology by supporting fileservice "modules".  You specify a path
 to serve and a name for the path, and clients request it by name instead of by
 path.  This provides the ability to conceal from the client unnecessary
 details like the local filesystem configuration.
 
 # File Format
 
 The default location for the file service is ``/etc/puppet/fileserver.conf``;
 this can be changed using the ``--fsconfig`` flag to ``puppetmasterd``.
 The format of the file is almost exactly like that of
 [rsync](http://samba.anu.edu.au/rsync/), although it does
 not yet support nearly the functionality of rsync.  The configuration file
 resembles INI-style files, but it is not exactly the same:
 
     [module]
         path /path/to/files
         allow *.domain.com
         deny *.wireless.domain.com
 
 These three options represent the only options currently available in the
 configuration file.  The module name somewhat obviously goes in the brackets.
 While the path is the only required option, the default security configuration
 is to deny all access, so if no ``allow`` lines are specified, the module will
 be configured but available to no one.
 
 The path can contain the patterns ``%h`` and ``%H``, which are dynamically
 replaced by the client's short name and its fully qualified domain name,
 both taken from the client's SSL certificate. This is useful in creating
 modules where files for each client are kept completely separately,
 e.g. for private ssh host keys. For example, with the configuration
 
     [private]
         path /data/private/%h
         allow *
 
 the request for file ``/private/file.txt`` from client
 ``client1.example.com`` will look for a file
 ``/data/private/client1/file.txt``, while the same request from
 ``client2.example.com`` will try to retrieve the file
 ``/data/private/client1/file.txt`` on the fileserver.
 
 # Security
 
 There are two aspects to securing the Puppet file server: Allowing specific
 access, and denying specific access.  By default no access is allowed.  There
 are three ways to specify a class of clients who are allowed or denied access:
 By IP address, by name, or a global allow using ``*``.
 
 ## Priority
 
 All ``deny`` statements are parsed before all ``allow`` statements, so if any
 ``deny`` statements match a host, then that host will be denied, and if no
 ``allow`` statements match a host, it will be denied.
 
 ## Host Names
 
 Host names can be specified using either a complete hostname, or specifying an
 entire domain using  the ``*`` wildcard:
 
     [export]
         path /export
         allow host.domain1.com
         allow *.domain2.com
         deny badhost.domain2.com
 
 ## IP Addresses
 
 IP address can be specified similarly to host names, using either complete IP
 addresses or wildcarded addresses, but you can also use CIDR-style notation:
 
     [export]
         path /export
         allow 127.0.0.1
         allow 192.168.0.*
         allow 192.168.1.0/24
 
 ## Global allow
 
 Specifying a single wildcard will let anyone into a module:
 
     [export]
         path /export
         allow *
 *$Id$*