hosts.conf

It is used to configure the hosts that should be administered using PICA. We can organize the hosts in different, possibly overlapped, groups that can be later used in conditions, so we could install a given file only in hosts belonging to a given group. We can also define variables for a given host and use them later. We also can specify different values for an object variable depending on the group we are working on by calling the ingroup sub.

Note that every host should be ``declared'' for PICA to know about it. It's a way to try to prevent you from shooting yourself in the foot.

A simple example of the hosts.conf file could be the following:

defaults {
   vars {
      ## ---- User defined variables ----
      docdir  = '/home/httpsd/html/red';
   }
}

##
## Hosts Definitions
##
host machine3;
host machine2 {
    vars {
       var = 'this variable sucks';
    }
}
host machine1;
host machine4;
host machine5;
host machine6;
host machine7;
host machine8 {
    fqdn = machine8.otherdomain.net;
}

###########################
# Host Group Definitions  #
###########################

##
## Group Definitions
##

## Servers
hostgroup servers {
    members { machine2, machine1, machine4, machine7, machine5, machine6 }
}

## RedHat Linux Servers
hostgroup redhat {
    members { 
        machine2, machine1, machine4, machine5, machine6
    }
}

## Debian Linux Servers
hostgroup debian {
    members { 
        machine8
    }
}

#####################
# Mail servers
#####################
## No relay
hostgroup mailmaster {
    members { machine2, machine1, machine4 }
}
## Mailing lists servers
hostgroup listservers {
    members { machine4 }
}
## Main domain server
hostgroup ulpgcmaster {
    members { machine4 }
}

################
## DNS Servers
################
hostgroup dnsservers {
    members { machine2, machine1, machine4, machine5, machine6 }
}
hostgroup dnsmaster {
    members { machine5, machine6 }
}

################
## NTP Service
################
## Stratum-2
hostgroup stratum2 {
    members { machine2, machine1, machine4, machine5, machine6, machine7 }
}

##
## GSM server
##
hostgroup sms {
    members { machine5 }
}

################
## Misc services
################
hostgroup imapservers {
    members { machine4 }
}
hostgroup popservers {
    members { machine4 }
}
hostgroup simapservers {
    members { machine4 }
}
hostgroup tftpservers {
    members { machine4 }
}
hostgroup ftpservers {
    members { machine4 }
}
#######################
## Some networks
#######################
hostgroup net1 {
    members { machine2, machine4, machine7 }
}
hostgroup net2 {
    members { machine1 }
}
hostgroup net3 {
    members { machine5, machine6 }
}
#########################################
## Documentation hosts
#########################################
hostgroup doc {
    members { machine5, machine6 }
}

Whoa! What a giant file. Well, perhaps you have noticed under all this mess that hosts (not hostgroups) can have attributes, such as ``fqdn''. This way we can specify host information such as the name PICA will use to create the secure connection. The list of possible host attributes is:

fqdn

As we already said, it sets the name PICA will use to connect to the host. If we don't specify it, PICA will use the host identifier (yes, the word after the reserved word ``host''). This attribute is useful if you have hosts in different domains and don't want to use the FQDN for the host definition. We can also define which user we want to connect as for a particular machine, with the ``sshuser'' attribute.

method

Is the method used to copy files to the host. Its possible values are ``ssh'' and ``tar''. It will be discused later, in page .

shellcmd

Is an attribute that specifies the complete command used to connect to the remote host. It uses the variables $sshargs and $cmd, which will be interpolated by the ssh arguments and the command to be executed, respectively. It defaults to `` $sshpath $\backslash$$sshargs picasshuser@$picafqdn $cmd''.

sshuser

The user we will connect to the machine with. It's usually root, but for some machines we would want to change the default.

defpathdir

Default path to install, for the objects with relative ``source'' attribute values and no ``path'' attribute.

One very important thing to note here is that this is the place where we can define the so called remote directories. We would like them to change in a per-host basis, but, by now, they are ``global'' to all hosts. Of course, chances are this will change sometime in the future. The list of remote directories is:

picaalarms

Directory where the alarms reside. In fact, directories with the name of the different priorities are created, and the alarms really reside there.

picabin

Where misc binaries will be installed, as scheduler.

picalib

Directory for collections of things.

picaobj

For objects used by alarms, mostly, like configuration files or data files.

Just one last note: it is possible to specify hostgroups in the ``members'' attribute of a hostgroup, so you can build hostgroup hierarchies. It's very useful if you have a group like ``DNS servers'' and subgroups like ``Windows DNS servers'' and ``Linux DNS servers'' (i.e.: perhaps you want to treat all DNS servers at once for some things, and separately for other things).