www.delorie.com/gnu/docs/cfengine/cfengine-Tutorial_76.html   search  
 
Buy GNU books!


GNU cfengine

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.3.2 Configuration file `cfservd.conf'

The server daemon is controlled by a file called `cfservd.conf'. The syntax of this configuration file is deliberately modelled on cfengine's own configuration file, but despite the similarities, you cannot mix the contents of the two files.

Though they are not compatible, `cfagent.conf' and `cfservd.conf' are similar in several ways:

Note that the classes in the `cfservd.conf' file do not tell you the classes of host which have access to files and directories, but rather which classes of host pay attention to the access and deny commands when the file is parsed.

Host name authentication is not by class or group but by hostname, like the `/etc/exports' file on most Unix systems. The syntax for the file is as follows:

 
 control:

   classes::

       domain = ( DNS-domain-name )

       cfrunCommand = ( "script/filename" )  # Quoted

       MaxConnections = ( maximum number of forked daemons )

       ChecksumDatabase = ( filename )

       IfElapsed = ( time-in-minutes )

       DenyBadClocks = ( false )

       AllowConnectionsFrom = ( IP numbers )

       DenyConnectionsFrom = ( IP numbers )

       AllMultipleConnectionsFrom = ( IP numbers )

       LogAllConnections = ( false/true )

       SkipVerify = ( IP numbers )

 groups:

   Group definitions

 import:

   Files to import

 admit: | grant:

   classes::

      /file-or-directory

        wildcards/hostnames

 deny:

   classes::

      /file-or-directory

        wildcards/hostnames root=hostlist encrypt=true/on

See the reference manual for descriptions of these elements. The file consists of a control section and access information. You may use the control section to define any variables which you want to use, for convenience, in the remainder of your file.

Following the control section, comes a list of files or directories and hosts which may access these. If permissions are granted to a directory then all subdirectories are automatically granted also. Note that plain-file symbolic links are not checked for, so you may need to specifically deny access to links if they are plain files, but cfservd does not follow directory symbolic links and give access to files in directories pointed to by these.

Fully qualified hostnames should be used in this file. If host names are unqualified, the current domain is appended to them (do not forget to define the domain name). Authentication calls the Unix function gethostbyname() and so on to identify and verify connecting hosts, so the names in the file must reflect the type on names returned by this function. You may use wildcards in names to match, for instance, all hosts from a particular domain.

Here is an example file
 
#####################################################
#
# This is a cfservd config file
#
#####################################################
 
groups:

  PasswdHost = ( nexus )

#####################################################
  
control:
  
  #
  # Assuming CFINPUTS is defined
  #

  cfrunCommand = ( "/var/cfengine/bin/cfagent" )  

  variable = ( /usr/local/publicfiles )

#####################################################
  
admit:   # Can also call this grant:
 
   PasswdHost::
 
     /etc/passwd
 
        *.iu.hioslo.no
 
    FtpHost::

    # An alternative to ftp, grant anyone 

       /local/ftp/pub
 
         *

    any::

       $CFINPUTS/cfrun.sh

         *.iu.hioslo.no

#####################################################
 
deny:
 
   /etc/services
 
       borg.iu.hioslo.no

  /local/ftp

       *.pain-in-the-ass.com


NOTE I: cfservd is not rpc.mountd, access control is by filename, not by device name. Do not assume that files lying in subdirectories are not open for access simply because they lie on a different device. You should give the real path name to file and avoid symbolic links.

NOTE II: access control is per host and per user. User names are assumed to be common to both hosts. There is an implicit trust relationship here. There is no way to verify whether the user on the remote host is the same user as the user with the same name on the local host.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

  webmaster   donations   bookstore     delorie software   privacy  
  Copyright 2003   by The Free Software Foundation     Updated Jun 2003