You may want to adjust the mailto or mailfrom. If you have a centralized reporting system like CFEngine Enterprise you may wish to disable agent emails all together. The preferred way of setting def. Now bootstrap the Agent to the Hub. Using the IP address from step 2 above, run the following command:. Sign up for CFEngine Enterprise and connect up to 25 hosts for free.
No credit card required. Get started in minutes. Here is an example module written in perl. Next we write the plugin itself. Thus instead of assigning actions for the class sun4 only you might define actions for any architecture by specifying: any:: actions If you don't specify any class at all then cfengine assumes a default value of any for the class. Node: Debugging tips , Next: Access control , Previous: The generic class any , Up: More advanced concepts Debugging tips A useful trick when debugging is to eliminate unwanted actions by changing their class name.
Since cfengine assumes that any class it does not understand is the name of some host, it will simply ignore entries it does not recognize. For example: myclass:: can be changed to Xmyclass:: Since Xmyclass no longer matches any defined classes, and is not the name of any host it will simply be ignored.
The -N option can also be used to the same effect. Node: Access control , Next: Wildcards in directory names , Previous: Debugging tips , Up: More advanced concepts Access control It is sometimes convenient to be able to restrict the access of a program to a handful of users. This can be done by adding an access list to the control: section of your program. For example, control Such a restriction would be useful, for instance, if you intended to make set-user-id scripts but only wished certain users to be able to run them.
If the access list is absent, all users can execute the program. Note: if you are running cfengine via the cfrun program then cfengine is always started with the same user identity as the cfd process on the remote host. Normally this is the root user identity. This means that the access keyword will have no effect on the use of the command cfrun. Node: Wildcards in directory names , Next: File sweeps , Previous: Access control , Up: More advanced concepts Wildcards in directory names In the two actions files and tidy you define directory names at which file checking or tidying searches should start.
One economical feature is that you can define a whole group of directories at which identical searches should start in one fell swoop by making use of wildcards. Cfengine opens each matching directory and iterates the action over all directories which match. The symbol? When this notation is used in directory names, it always defines the starting point for a search. It does not tell the command how to search, only where to begin.
The pattern directive in tidy can be used to specify patterns when tidying files and under files all files are considered, see Reference manual , Node: File sweeps , Next: Log files , Previous: Wildcards in directory names , Up: More advanced concepts File sweeps File sweeps are searches through a directory tree in which many files are examined and considered for processing in some way.
There are many instances where one uses cfengine to perform a file sweep. As part of a files action, for checking access rights and ownership of files. As part of a tidy action, for checking files for deletion. As part of a copy action, while recursively checking whether to copy a file tree. The problem with file sweeps is that they can be too sweeping! Often you are not interested in examining every single file in a file tree.
You might wish to perform a search excluding certain named directories and their subdirectories with ignore. The tidy action is slightly different in this respect, since it always expects to match a specific pattern.
One is generally not interested in a search which deletes everything except for a named pattern: this would be too dangerous. For this reason, the syntax of tidy is different and is documented in the section on tidying, see Reference manual. Items declared under the global ignore section affect files, copy, links and tidy. If you include patterns in this way, cfengine ignores any files which do not match the given patterns.
In other words, exclusions always override inclusions. If you exclude a pattern or a directory and wish to treat it in some special way, you need to code an explicit check for that pattern as a separate entity. For example, to handle the exluded. The quotes will be treated literally and the pattern might not match the way you would expect. Node: Log files , Next: Quoted strings , Previous: File sweeps , Up: More advanced concepts Log files written by cfengine Cfengine keeps two kinds of log-file privately and it allows you to log its activity to syslog.
Syslog logging may be switched on with the Syslog variable, see Reference manual. The first log cfengine keeps is for every user every subdirectory of a home directory filesystem. This is useful for users who want to know files have been removed without their blessing. This helps to identify what is happening on the system in case of accidents. Another file is built when cfengine searches through file trees in the files action. This is a list of all programs which are setuid root, or setgid root.
Since such files are a potential security risk, cfengine always prints a warning when it encounters a new one one which is not already in its list. This allows the system administrator to keep a watchful eye over new programs which appear and give users root access.
The file is not readable for general users. Node: Quoted strings , Next: Regular expressions , Previous: Log files , Up: More advanced concepts Quoted strings In several cfengine commands, you use quoted strings to define a quantity of text which may contain spaces. The same goes for the other types of string delimiters. Unlike the shell, cfengine treats these three delimiters in precisely the same way. There is no difference between them. If you need to quote a quoted string, then you should choose a delimiter which does not conflict with the substring.
Note that you can use special variables for certain symbols in a string See Variable substitution. Node: Regular expressions , Next: Iterating over lists , Previous: Quoted strings , Up: More advanced concepts Regular expressions Regular expressions can be used in cfengine in connection with editfiles and processes to search for lines matching certain expressions.
A regular expression is a generalized wildcard. Regular expressions are more complicated than wildcards, but have far more flexibility. Some regular expressions match only a single string. For example, every string which contains no special characters is a regular expression which matches only a string identical to itself.
Thus the regular expression cfengine would match only the string "cfengine", not "Cfengine" or "cfengin" etc. Other regular expressions could match more general strings. Thus this expression would match the empty string, "c", "cccc", "ccccccccc", but not "cccx".
Here is a list of regular expression special characters and operators. If no object precedes it, it represents a literal asterisk. Match zero or one instance of the preceding object.
Clearly the first number must be less than the second to make a valid search expression. The logical OR operator, OR's any two regular expressions. Groups together any number of operators. Here is a few examples. Remember that some commands look for a regular expression match of part of a string, while others require a match of the entire string see Reference manual. This gives us a compact way of writing repeated operations and it allows a simple method of communication with the shell environment.
This typically allows communication with PATH-like environment variables in the shell. In these contexts, any variable which has the form of a list joined together by colons will be iterated over at compilation time.
Note that you can change the value of the list separator using the split variable in the control section of the program see Reference manual. The number of list variables in any path or filename should normally be restricted to one or two, since the haphazard combination of two lists will seldom lead to any meaningful pattern. The only obvious exception is perhaps to iterate over a common set of child-directories like bin , lib etc in several different package directories.
Node: Global configurations , Next: Using cfengine as a front-end for cron , Previous: More advanced concepts , Up: Top Designing a global system configuration This chapter is about building strategies for putting together a site configuration for your entire network. General considerations : Using netgroups : a common database for classes Files and links : Copying files : Managing processes : NFS resources : the cfengine model Using the automounter : Editing files : Disabling and the file repository : Running user scripts : Compressing logs : ACLs : Node: General considerations , Next: Using netgroups , Previous: Global configurations , Up: Global configurations General considerations In order to use any system administration tool successfully, you have to make peace with your system by deciding exactly what you expect and what you are willing to do to achieve the results.
You need to decide what you will consider to be acceptable and what is to be considered completely untenable. You need to make these decisions because otherwise you will only be confused later when things don't go the way you expected.
Experience shows that the most successful policies for automation involve keeping everything as simple as possible. The more uniform or alike your machines are, the easier they are to run and the happier users are.
Sometimes people claim that they need such great flexibility that all their machines should be different. This belief tends to be inversely proportional to the number of machines they run and generally only applies to very special development environments! Usually you will only need one or to machines to be special and most can be made very similar.
Site configuration is about sharing and controlling resources. The resources include disks filespace , files, data, programs, passwords and physical machines. Before planning your sitewide configuration you should spend some time deciding how you would like things to work. In the remaining parts of this chapter, you will find some hints and tips about how to proceed, but remember that when push comes to shove, you must make your own choices.
Node: Using netgroups , Next: Files and links , Previous: General considerations , Up: Global configurations Using netgroups If you use the network information service NIS on your local network then you may already have defined netgroups consisting of lists of hosts which belong to specific owners at your site. If you have, then you can use these groups within cfengine.
A netgroup is a list of hostnames or user names which are registered in the network information service NIS database under a specific name. In our case we shall only be interested in lists of hostnames. If you are not the NIS administrator, you will have to ask to have a netgroup installed. The form of a netgroup list of hosts is: mylist-name host1,, host2,, host3,, host4,, norway-sun4-host saga,, tor,, odin,, foes-linux-hosts borg,, Each list item has three entries, but only the first is relevant for a host list.
See the manual pages on netgroups for a full explanation of the meaning of these fields. This compresses the amount of text in this file from a long list to a single name. It also means that if you use the same list of hosts from a netgroup inside cfengine when defining groups and classes, you can be sure that you are always using the same list. In particular it means that you don't have to update multiple copies of a list of hosts. Actions are divided into three categories called files , tidy and links.
The first of these is used to check the existence of, the ownership and permissions of files. The second concerns the systematic deletion of garbage files. The third is a link manager which tests, makes and destroys links. The monitoring of file access bits and ownership can be set up for individual files and for directory trees, with controlled recursion. From this point the search for files proceeds recursively into subdirectories with a maximum limit set by the recurse directive, and various options for dealing with symbolic links and device boundaries.
The mode-string defines the allowed file-mode by analogy with chmod and the owner and group may specify lists of acceptable user-ids and group-ids. The action taken in response to a file which does not meet acceptable criteria is specified in the action directive.
It includes warning about or directly fixing all files, or plain files or directories only. Safe defaults exist for these directives so that in practice they may be treated as options. By default, fixall causes the permissions and ownership of the files to be fixed without further warning.
Since cfengine can make many hundreds of links without any effort, there is the danger that, in time, the system could become full of links which don't point anywhere. If this is set, cfengine will remove any symbolic links which do not point to existing files see Reference manual. The creation of symbolic links is illustrated in figure 1 and the checking algorithm was discussed in section 2. In addition to the creation of single links, one may also specify the creation of multiple links with a single command.
A further facility makes use of cfengine's knowledge of available mounted binary resources to search for matches to specific links. Readers are referred to the full documentation concerning this feature. The need to tidy junk files has become increasingly evident during the history of cfengine. Many users use these areas for receiving large ftp-files so that their disk usage will not be noticed! To give another example, just in the last few months the arrival of netscape World Wide Web client, with its caching facilities, has flooded hard-disks at Oslo with hundreds of megabytes of WWW files.
In addition the regular appearance of core files 1 and compilation by-products. The problem is easily remedied by a few lines in the cfengine configuration. Files can be deleted if they have not been accessed for n-days. Recursive searches are both possible and highly practical here. Cfengine tests the access time of files and deletes only files older than the specified limits. Hence all core files, in this example, are deleted immediately, whereas files in the subdirectory.
As a system administrator you should, of course, exercise great caution when making rules which can delete users' files. A single slip of the hand can result in a rule which will irretrievably delete files.
You should not delete files until after you have taken a backup, so that -- if the worst should happen -- you are covered against possible accidents.
Cfengine helps to some extent to keep track of what files it deletes. When tidying users' home directories it creates a log file of all files which were deleted on the last tidy operation. You might consider tidying certain files only once a week, in which case a command such as tidy: AllHomeServers. Sunday:: files to tidy could be useful. Be careful when telling cfengine to delete core files. Node: Copying files , Next: Managing processes , Previous: Files and links , Up: Global configurations Copying files The administration of a system often requires the copying of files.
The reason for this is usually that we would like to distribute a copy of a particular file, from some master location and ensure that all of the copies are up to date. Cfengine helps this process by allowing you to copy a single file or a file tree, from one directory to another, perhaps checking the permissions and owners of a file to adjust the copies in some special way.
The files are checked by cfengine using one of two methods. A date-stamp comparison with a master file, using last-change times, can be used to tell cfengine to recopy a file from the master if the master file is newer than the copy. A checksum can be computed for each file and compared with one for the master file.
If the contents of the copy file differs in any way from the master, the file will be re-copied. Cfengine allows you to do the following Copy a single file to another file in a different location, perhaps with a new name, new permissions and a different owner. Copy a single file to all users on the system, changing the owner of the file for each user automatically. This could be used to distribute and update standard setup files. Recursively copy an entire file tree, omitting files which match a list of wildcard-patterns, or linking certain files instead of copying.
You can find out more about copying in the reference section. Node: Managing processes , Next: NFS resources , Previous: Copying files , Up: Global configurations Managing processes Cfengine allows you to check for the existence of processes on your system, send those processes signals such as kill and perhaps restart those processes.
Typical applications for this are sending cron and inetd the HUP signal, after editing their configuration files, or killing unwanted processes such as user programs which hog the system at peak usage times. You can read more about this in the reference section. Node: NFS resources , Next: Using the automounter , Previous: Managing processes , Up: Global configurations Cfengine's model for NFS-mounted filesystems Most of the filesystems that you will want to make available across the network are going to fall into one of two categories.
In cfengine parlance these are called home directories and binary directories. A home directory is a place where users' login directories are kept. A binary directory is a place where compiled software is kept. In this chapter we shall consider a scheme for using cfengine to make NFS filesystem management quite painless.
NFS filesystem resources : a conceptual introduction Unique filesystem mountpoints : avoiding collisions How does it work? The idea of NFS is to share files on one host with other hosts. In most cases, filesystems to be shared across the network fall into two categories: binary filesystems those which contain compiled software and user or home filesystems which contain users' login areas. The most simple minded way to share resources would be to mount every resource each available NFS filesystem onto every host.
To avoid collisions, each filesystem would have to have a unique name. This is one possibility, but not a very intelligent one. As experienced users will realize, cross-mounting too many NFS filesystems is a recipe for all kinds of trouble. Cfengine offers a simple model which can help you pick out only the resources you need from the list of NFS filesystems.
It will then mount them automatically and edit the appropriate filesystem tables. It does this by defining classes of hosts. For instance -- you really don't need to mount a binary filesystem for an ultrix system onto an HPUX system. There would be no point -- binary resources are architecture or hard-class dependent. But home directories are architecture independent. Cfengine lets you to define a list of allowed servers for various hosts so that only filesystems from the servers will be considered for mounting!
Node: Unique filesystem mountpoints , Next: How does it work? A simple but extremely useful naming scheme is the following. If you follow this scheme, exactly as described here, you will never have any problems with mount points. We shall describe the scheme in detail below. Here are some points to digest: When mounting a remote filesystem on your local system, the local and remote directories should always have exactly the same name.
The name of every filesystem mountpoint should be unique and tell you something meaningful about where it is located and what its function is.
If you this involves compiled software and you do this on one host, you should do it on others which are of the same type. It doesn't matter whether software compiles in the path names of special directories into software as long as you follow the points above. It could be your company name or whatever. The second piece is the name of the host to which the disk space is physically attached.
The final piece is the name of the filesystem. This is because it makes the procedure of organizing the entire network much clearer.
The whole naming convention is compactly summarized by defining a mount point variable, mountpattern. This variable is used together with the homepattern pattern variable, which is used to distinguish between home directories and binary resources.
See homepattern in the reference section. You can think of this as being part of the naming convention. In this text, we use the convention u1 u2 u You could equally well use home1 home As long as the name is unique, it doesn't matter. The full list of named resources should now be listed in the mountables list, which is simply a list of all the resources available for mounting on the network.
Node: How does it work? Once you have defined your unique names, how does cfengine know what to mount? The idea is now to define a list of servers for each class of hosts. Suppose we make a binserver declaration: binservers: mygroup. Every filesystem which is listed in mountables and is not a home directory will be mounted. Home directories and binary resources are kept separate automatically by cfengine, because a home directory is one whose contents-name matches the homepattern pattern variable.
See Unique filesystem mountpoints. A homeserver declaration: homeservers: mygroup:: einstein newton schwinger feynman would correspondingly mean mount all the home directory resources on the hosts in the list on all hosts in the group mygroup. Clearly it is unnecessary to distinguish between the architecture platform types of the actual servers for user directories.
In each case, cfengine will mount filesystems, make the appropriate directories for the mount point and edit the filesystem table. In practice, cfengine goes through the list in order and picks the first filesystem resource which matches. Could this lead to a collision? That means that if you have a local filesystem, it will always have priority. This means that you should structure the actionsequence so that all filesystems are mounted before any links are made.
With a little practice, the cfengine model can lead to an enormous simplification of the issue of NFS-mountable resources. NOTE: cfengine does not try to export filesystems, only mount already exported filesystems. In practice this is very difficult to do and perhaps not desirable. Node: Mount example , Previous: Special variables , Up: NFS resources Example programs for mounting resources Let's write a very simple configuration for a network with only one server called hal, where all the hosts are of the same operating system type.
In such an example we can avoid using classes altogether. If we look through the action sequence we see that the program first mounts all the filesystems which are already defined on each host.
It does this to be sure that everything which is already set up to be mounted is mounted. Let's assume that there are no problems with this. The next thing that happens is that mountinfo builds a list of the filesystems which each host has successfully mounted.
Then by calling addmounts we ask cfengine to check whether the host is missing any filesystems. What happens is that cfengine first looks to see what servers are defined for each host. In this case all hosts on the network have only one server: hal. The list mountables tells cfengine what filesystems are available over the network for the server hal.
Cfengine checks to see whether each of these filesystems is mounted and, if not, it builds the necessary directories, edits the necessary files and mounts the filesystems.
Finally we come to links in the action sequence. This tells cfengine to look at the defined links. Cfengine checks and tries to make the link if necessary. Here we have several servers and must therefore use some classes. This host belongs to the class mygroup and the hard-class ultrix. This tells us that its homeserver is host1, its binary server is server2 and its mailserver is host1. Moreover, since the homepattern matches any filesystem ending in u-something, it recognizes the two home directories in the mountables list -- and therefore the two binary directories also.
It then scans the list of mounted filesystems to find out what is actually mounted. The mail server is also checked for and added if necessary. Cfengine then tries to mount all filesystems once again, so that the new filesystems should be added. If something prevents this -- if we try to mount on top of a plain file for instance -- then this will result in an error. Finally, we reach the link section and we try to expand the variables. The script is then completed. If the script is run again, everything should now be in place so nothing happens.
If for some reason it failed the first time, it will fail again. At any rate it will either do the job once and for all or signal an error which must be corrected by human intervention 4.
Note: If you want to manage multiple machines using your Ubuntu server, you will have to repeat steps 1, 2, and 3 on each of the machines. However, in Step 4, to configure the machines as just clients, you should bootstrap them with the IP address of your current Ubuntu server i. To automate a system administration task using CFEngine, you should create a policy file for it.
The language has a rather steep learning curve, but performing basic tasks with it is easy. Use nano or your favorite text editor to create a new file called myPolicy. The commands you want to execute using CFEngine should be grouped together in a bundle. Bundles can be of different types. For now, you will be creating a bundle that cf-agent can fun.
To print a message to the console, the reports promise should be used. Accordingly, add the following code to the file:. In the previous step, you ran the policy manually using the cf-agent command.
To run the policy automatically — and, more importantly, on multiple machines — you should add it to the policy server. By default, policies added to the server are executed once every 5 minutes by cf-agent.
0コメント