Pp. 123–138 of the Proceedings

Abstract

In an ideal world, the system administrator would simply specify a complete model of system requirements and the system would automatically fulfill them. If requirements changed, or if the system deviated from requirements, the system would change itself to converge with requirements. Current specialized tools for convergent system administration already provide some ability to do this, but are limited by specification languages that cannot adequately represent all possible sets of requirements. We take the opposite approach of starting with a general-purpose logic programming language intended for specifying requirements and analyzing system state, and adapting that language for system administration. Using Prolog with appropriate extensions, one can specify complex system requirements and convergent processes involving multiple information domains, including information about files, filesystems, users, and processes, as well as information from databases. By hiding unimportant details, Prolog allows a simple relationship between requirements and the scripts that implement them. We illustrate these observations by use of a simple proof-of-concept prototype.

Introduction

Lately, the task of system configuration has been greatly eased by tools that automatically enforce compliance with a model of proper system operation and health via 'convergent processes' that detect and correct deviations from the model. System management then becomes a matter of crafting the model of appropriate behavior or configuration. This model contains 'rules' that specify proper behavior and configuration together with 'actions' that specify what to do to correct any discovered lack of compliance with a given rule.

Unfortunately, crafting such a model is difficult due to the number of different kinds of rules and actions involved in creating a complete model. These range from high-level operating policies to specification of dynamic operating behavior. First we must specify operating policy, a high-level description of how the system should behave and what services should be offered. We must then translate this high-level behavioral description to a description of the contents and disposition of system files that will insure this behavior. We can call this description the static configuration of the system, because the requirements it describes should not change over time, and typically we can insure these requirements are met with a single script or scripts, executed once. The system then begins operation and interprets these files in order to operate, so that other content does change over time. We can call the things that change over time part of the dynamic configuration of the system. To conform this to our requirements, we can craft convergent processes that observe the dynamic configuration of the system and modify system performance to match our models.

Static Configuration

There are now an endless variety of tools available for incrementally assuring desired static configuration of a system or network, beginning with the legacy of make [22] and rdist [8], both of which control file state based upon incremental generation and copying rules. The ideas in these tools are now pervasive and have made their way into almost all tools for configuration management. Package managers such as the RedHat Package Manager (RPM) [2] and Depot [7, 21, 28] only install requested software packages if those packages are not already present. Our own tool Slink [9, 10] and its relatives, including GNU Stow [14], incrementally modify a symbolic link tree to conform to a desired structure, while our own tool Distr [11] allows 'push' and 'pull' convergent file distribution, utilizing filters to translate file formats for differing platforms.

Cfengine [3, 4, 5] makes it possible to define and converge to very complex and expressive models of system state. Cfengine provides a powerful configuration language with built-in operations that act on files, links, directories, mounts, and even processes. Extensive built-in stream editing commands allow us to incrementally edit system files to conform with requirements, freeing us from having to store file prototypes on a master server.

All these static configuration tools share the same strengths and limits. Configuration files are relatively simple and easy to construct. The process by which one assures conformance with a configuration file is obvious and automatic. However, with the exception of a small number of database-driven prototypes, these tools specify system configuration at a fairly low level of abstraction, telling what to do to specific file contents.

One would like, instead, to simply list desired services and have the tool determine what to place in each file to implement each desired service. An ideal tool would query a distributed database or directory service, such as the Lightweight Directory Access Protocol (LDAP), for a high-level description of the services required on the system in question. Based upon the list of services to be offered, the tool would then proceed to modify all files requiring changes in order to provide that service. This kind of configuration power would require that the configuration tool know the mapping between services and file contents for each target operating system. This, in turn, requires maintenance of rather simple, detailed databases of system information that have little or nothing to do with operating policy: where files are, how configuration files are structured, etc.

Dynamic configuration

Historically, dynamic configuration has been preserved and enforced by a completely different set of tools than those used for managing static configuration. While static configuration tools rely heavily on databases, lists, and other declarative mechanisms for specifying configuration, dynamic configuration tools have relied upon user-crafted scripts. To use a tool, the administrator specifies behavioral patterns to detect and scripts to execute when each pattern is detected.

Current dynamic configuration tools allow monitoring of dynamic state, including processes, logfiles, and filesystems. Early tools were system log monitors, such as Swatch [15] and the more recent LogSurfer [18], which can page operators or run other scripts when potentially harmful events are posted in the system logs. These simple monitors have evolved into powerful tools that can monitor global system state, including TripWire [16, 17], which checks whole filesystems for compliance with a previous recorded state, and SyncTree, which can restore previous states of a system even if they are changed maliciously by a hacker [19].

Many system administrators resign themselves to writing custom scripts to monitor and correct problems in UNIX networks. These scripts interact with the same UNIX commands, and perform the same tasks, but must be customized for each site and platform, leading to massive duplication of effort. PIKT [24] (pronounced 'picket') greatly reduces the effort in writing scripts for multiple platforms and tasks, by providing a class mechanism for determining applicability of script parts and a powerful set of built-in parsing primitives (reminiscent of command parsing available in Tcl/TK [23]) for accessing the text output of UNIX status commands such as ls and netstat. Similar scripts for different platforms can be organized into a single script with class qualifiers, where appropriate lines in the script will be utilized for each target platform.

PIKT works well but, like the custom scripts it allows one to catalog, there is an uncomfortable distance between the scripts that implement policy and the policies they implement. A policy that is relatively simple to describe, such as "delete all core files more than three days old" might be written as the find command:

find /home -name core -mtime 3 \
         -exec rm -rf {} -print;

Ideally, we should be able to document operating policy and automatically translate the documentation into scripts that implement the policy. Ironically, the typical administrator in a hurry will document only the scripts. To determine what operating policies are, one must read and interpret what the scripts mean. Most administrators are not paid to write scripts, but to insure quality of service, so that script writing is done in great haste and with no attention to readability or potential software life-cycle. So documenting the actual operating policy for a network requires reverse-engineering the operating policy from the scripts on an ongoing basis.

Again, we need some way to automatically translate between a high level description of operating policy and the script that implements it, so that we no longer have to read and understand a script to understand the policy it implements. There must be a way to craft scripts that is in some way 'closer' to the natural way we would describe policy: a language closer to specifying what we want rather than how to accomplish it.

Databases

Many administrators have come to rely on databases [12], both normal and directory-based (such as LDAP or NIS+), to describe static network state. A database is a structured data storage and retrieval method, consisting of tables of information, where each table is organized into rows and columns. Database information is usually manipulated and accessed by use of Sequential Query Language (SQL), which specifies how to access individual rows and columns, and how to create new tables whose rows and columns can then be accessed.

Databases have several advantages over plain files. They can be accessed from anywhere in a network using standardized network access methods. Isolated parts of a database table can be incrementally modified with no chance of corrupting other parts of the table. When information is volatile, but must be modified and accessed in small chunks, databases provide more reliability than unstructured files.

Databases become very useful in maintaining information about the external world outside the systems being maintained, such as information on each user's true identity and function. A typical application would be to record information about each user in a database, and then use that information to compute appropriate filesystem and mail quotas for the user.

Unfortunately, normal database access methods such as SQL do not allow one to specify how to act based upon database contents. One must call SQL from another language empowered to take action. So to use databases, we are forced to learn both SQL and a scripting language (such as Perl [26]) for crafting actions based upon SQL queries. How, then, can we utilize databases without having to simultaneously write in two scripting languages: one for database access and another to react to content?

Toward a 'Glue Language'

We seek to fulfill Burgess' dream of 'Computer Immunology' [5], in which a description of computer 'health' empowers computers to 'immunize' themselves against poor function, thus becoming self-repairing and correcting. We began the work of this paper by searching for a common language that one could use for specifying both static and dynamic configuration. If we could find such a 'glue language,' we would be one step closer to being able to write scripts that describe operating policies with true platform independence. The language had to be able to provide at least a superset of the combined capabilities of Cfengine and PIKT. As well, we desired a language that:

• allows both static and dynamic requirements, limits, and convergent processes to be specified with the same syntax.
• is extensible to provide interfaces to all conceivable kinds of data and actions.
• allows specification of high-level rules that codify all steps in providing one user service, so that users can simply ask for the service rather than describing its low-level modifications.
• interoperates well with structured forms of information storage such as databases and directory services.

Prolog As a Database Query Language

Prolog [6] is a much misunderstood language with an somewhat undeserved reputation for inefficiency and difficulty of programming. In reality, Prolog is one of the most efficient mechanisms for making queries into databases and writing action scripts based upon database queries. As well, Prolog has unique implicit properties that make programs shorter and easier to read, by omitting details that the language can handle by itself. For example, both conditional statements and loops are implicit in Prolog, and their use is determined by context.

We explored the powers of this language by constructing a prototype interface between Prolog and the operating system on a single host, with the intent of creating Prolog utilities that duplicate the functionality of Cfengine and PIKT. Then, we experimented with the prototype to determine its strengths and weaknesses.

Prolog syntax

Programming in Prolog is very different from programming in a normal scripting language. Rather than saying what should happen, one declares what should be true. The Prolog interpreter translates those declarations into actions to perform. This is called declarative programming.

A Prolog 'program' consists of facts and rules. A fact can be thought of as a line entry in a table in a database. The fact:

login(couch).

Facts can be pre-recorded in Prolog's databases, or can be computed by external functions written in C or other languages. For example, in our prototype, we compute facts of the form

passwd(couch,
 '3hit2839482912',
 1000,
 40,
 'Alva L. Couch',
 '/home/couch',
 '/usr/bin/tcsh').

A Prolog rule tells how to make more complex facts from simpler ones. For example, the rule:

pig(Login):-
 passwd(Login,_,_,_,_,Home,_),
 du(Home,Usage),
 Usage>20000.

A rule has a left hand and right hand side separated by :-. The left-hand side specifies the goal of the rule, which in this case is to find a value for the variable Login. The right-hand side consists of subgoals needed to accomplish a goal. The symbol :- is read 'if', and commas between terms on the right hand side represent 'and'. Login, Home, and Usage are variables because they begin with capital letters. The special symbol "_" (the anonymous variable) is a place holder that indicates that a value in a query should be ignored. In this rule, for example, we can ignore the user's password, uid, gid, name, and shell.

Queries

In order to get Prolog to actually do anything, one has to execute a query. This is a request to compute values of variables based upon known facts and rules. For example, to request a list of pigs, from the rule above, we could type this in the Prolog interpreter:

?- pig(X).

X=couch ;
X=bgates ;
No.

Whenever Prolog needs to determine who is and who is not a pig, it uses the rule above to compute who all the pigs are. Prolog begins with no idea of who a pig is, and evaluates the subgoals in the rule on the right hand side of the 'if' from left to right. The first subgoal, passwd(Login,_,_,_,_,Home,_) sets Login to each login name in turn, and sets Home to the corresponding home directory of Login. Then the second term, du(Home,Usage) computes the disk usage for that directory (by scanning the home directory) and sets Usage to that value. The last subgoal, Usage>20000, checks the value Usage. If it is greater than 20000, the goal pig(Login) succeeds. This has the result of returning whatever Login value we found as the result of the query. In this case, we wanted X's, so each match is assigned to X and printed for us.

Backtracking

Queries are repeatedly satisfied through backtracking. To backtrack, Prolog backs up from right to left in the list of subgoals it is attempting to complete, and tries new values for variables. For example, we implemented passwd/7 so that when backtracking, passwd(Login,_,_,_,_,Home,_) will set Login and Home to the information for each user in the system, one per try. Through backtracking, the rule above can potentially check 2000 users for pigdom. After finding a new value for Login and Home, Prolog then continues trying to execute goals from left to right. Whenever it satisfies all subgoals of a goal, and gets to the end of the rule, Prolog returns a match.

In this way, Prolog enumerates all possible matches for each rule, as demonstrated above. Every Prolog goal potentially tries all reasonable values for each variable, so that one never has to write a 'for' loop in Prolog. This also means that the easiest program to write in Prolog is an infinite loop!

Backtracking is as tricky and dangerous as it is powerful. Suppose that instead of the preceding rule for pig/1, we wrote:

pig(Login):-
 du(Home,Usage),
 passwd(Login,_,_,_,_,Home,_),
 Usage>20000.

Performance is seriously affected by the way in which we write a Prolog rule. The original pig/1 rule finds all the pigs in a system roughly as quickly as a Perl script written to do the same thing. But suppose we instead write:

pig(Login):-
 passwd(Login,_,_,_,_,_,_),
 passwd(Login,_,_,_,_,Home,_),
 du(Home,Usage),
 Usage>20000.

Our first version of passwd/7 read and cached the whole NIS+ password table before returning each entry. This meant that the rule above did that twice. First, it backtracked through all values for Login, and then checked them against all values for Login in order to find a matching one and determine its Home. Since we have about 1000 users, the rule thus checked 1000 entries 1000 times in backtracking to satisfy both subgoals. This took forever.

We then re-implemented passwd/7 so that if Login is initially bound to a value, passwd/7 uses getpwnam rather than getpwent to match information instantly. The second subgoal passwd(Login,_,_,_,_,Home,_) thus does not try all combinations, but instead instantly returns the appropriate home directory. This change made the above example execute several thousand times faster, but it still takes about twice the time of the original, more efficient rule with one subgoal for passwd/7.

Unification

In converging toward system health, we wish to force our idea of what should be true to actually be true. In Prolog nomenclature, we wish to unify our idea of what reality should be with the state of a particular machine.

In a Prolog rule, variables begin their lives having no value whatsoever, and are called unbound. Variables become bound, or set, by being unified with constants or other variables. The way this works depends upon how built-in and external functions are designed, and functions can behave differently depending upon whether variables given to the function are bound or unbound. In evaluating the goal:

passwd(Login,_,_,_,_,Home,_)

• if Login and Home are unbound, then the query tries to bind Login and Home to each valid pair in the password table (in our case, via NIS+ naming service).
• If Login is bound but Home is unbound, then Home is unified with the corresponding home directory, if any.
• If Home is bound but Login is unbound, then Login is unified with each login name with that home directory in turn (and there may be more than one)!
• If Login and Home are both bound, then the query 'succeeds' if they are a valid pair, and 'fails' if they are not paired correctly.

The result is that after any 'success', Login and Home form a valid pair, regardless of how that pair arose. A general-purpose goal like this can be used in many contexts, with variables known and unknown, and will adapt to the context and respond appropriately. Given a small amount of information, of any kind, this rule determines the rest if possible. Prolog goals (the left hand sides of rules) are called functors (rather than functions) precisely because they are capable of setting variables in a very flexible way, and using the same variables as both input and output.

Goals That Modify Configuration

In using SQL to manipulate tables of configuration information, one must use a different language for actions than for queries. Not so in Prolog. There is no reason that a goal cannot modify the external world in order to satisfy a query. Consider the simple example of a goal that returns the owner and group of a file specified as a pathname:

path_owner(Path,Owner,Group).

?- path_owner('/etc/motd',
              Owner,Group).

?- path_owner('/etc/motd',0,0).

The ambiguity between goals and actions in Prolog can be exploited to construct many rules that implement both at once. If we write a goal copy(Source,Target) that insures that the file Source is identical with node Target, then goal succeeds if it can make the files identical and fails if it cannot. Then we can write:

?- copy('/Master/etc/motd',
        '/etc/motd').

Such lingual power comes with a price. Structured programmers should cringe, because we have all been taught that programs should not contain 'side-effects' that change things other than program variables. In the above, we are executing 'ambiguous' goals that check and assure system states solely for their side effects! This can make Prolog programs difficult to interpret and maintain.

Careless implementation and use of convergent Prolog goals can lead to disaster. Suppose that we implemented the passwd/7 functor so that it was able to set any field to a desired value, as a side effect, as well as iterating over all password records. Then the query:

?- passwd(_,_,30,_,_,_,_).

Implicit Iteration

Suppose we want to tell all pigs what we think of them. In Prolog, iterating over all matches for a variable is implicit. One never has to write a for or foreach loop; any query will search through all possible options. For example, if we type:

?- pig(Login),
   email(Login,
         'you are a pig!',
         'oink!'),
   fail.

Implicit execution is both a curse and a blessing. The good news is that one never needs to write a 'for' loop again. But interpreting what Prolog code actually does can be difficult. A safe way to interpret a Prolog program is to mentally put the phrase "for all values of variables so that" in front of every goal.

Controlling Implicit Loops

Sometimes we may wish to prohibit this behavior, e.g., make an example of one pig. The special goal ! (the cut) tells Prolog not to try to backtrack to the goals on its left-hand side. We could type:

?- pig(Login),!,
   email(Login,
         'you are a pig!',
         'oink!'),
   fail.

Prolog and Cfengine

So far we have shown only how to construct specific queries that have particular effects, by manually interacting with the Prolog interpreter. How, then, does one automate the process of configuring a complete system? As with Cfengine, we must craft a set of rules that describe when the system is healthy. We can learn much from how Cfengine rules accomplish the same task.

Cfengine is 'almost as powerful' as a real Prolog interpreter, and only falls short in its handling of variables and extensibility. To control whether and how to do something with a particular machine, Cfengine uses 'classes'. A 'class' is a variable that is either true or false, depending upon the machine in question. In configuring Cfengine, one qualifies each action with the conditions under which it should occur, expressed as a boolean expression of classes. For example, in the Cfengine code:

links:
  solaris.victim::
    /etc/sendmail.cf
      ->! mail/sendmail.cf

Classes in Cfengine correspond roughly with Prolog facts of arity 0. Facts are present (and thus 'true') if they depict the current operating environment. When Cfengine starts executing, it discovers as many facts as it can about the system upon which it is executing. For a machine hillary, running Solaris 5.7, these include classes equivalent to the Prolog facts:

hillary.
solaris.
sunos_5_7.

Cfengine variable assignments, such as

groups:
 victim = ( bill hillary monica )

victim:-bill.
victim:-hillary.
victim:-monica.

This simplicity gives Cfengine incredible speed, as it never needs to deal with classes with values other than true or false: true if a fact is true in this environment, false if not. Prolog is slower, but as a result of this slowness, gains the ability to customize administrative process far beyond Cfengine's capabilities.

Cfengine class qualifications correspond with qualification goals in Prolog rules, where all qualifications have arity 0. For example, the Cfengine rule:

links:
  solaris.victim::
    /etc/sendmail.cf
      ->! mail/sendmail.cf
    /etc/services
      ->! inet/services

links:-solaris,victim,
       link('mail/sendmail.cf',
            '/etc/sendmail.cf').
links:-solaris,victim,
       link('inet/services',
            '/etc/services').

The control: section of Cfengine's configuration file specifies the sequence in which individual goals are assured. For example, the Cfengine configuration:

control:
  actionsequence = ( links copy )

health:-links,fail.
health:-copy,fail.
?- health,fail.

Genericity

Cfengine has been a great inspiration to us, and is a crucial element in day-to-day operation of our site, but its limitations forced us to look elsewhere for a truly general-purpose language for configuring systems. Cfengine is fantastic for manipulating files, but is very difficult to use to create generic, platform-independent, reusable configuration instructions for implementing high-level services.

Using any tool, any time a system file can vary in location or format, one must construct a new special case rule or macro to handle the deviations. In Cfengine this process becomes unwieldy very quickly, as macros in Cfengine all inhabit one name space, and one must remember the meanings of all of them in order to write new rules.

For example, let us learn to deal with an inetd.conf file that moves between /etc/inetd.conf and /etc/inet/inetd.conf depending upon operating system. One can cope with this in Cfengine as follows:

editfiles:
 ftp.solaris::
  { /etc/inet/inetd.conf
    AppendIfNoSuchLine \
     "ftp stream tcp nowait root \
     /usr/sbin/in.ftpd in.ftpd"
  }
 ftp.osf::
  { /etc/inetd.conf
    AppendIfNoSuchLine \
    "ftp stream tcp nowait root \
     /usr/sbin/ftpd ftpd"
  }

Using Cfengine macros, it is possible to code the same operation somewhat more neatly:

control:
 solaris::
  inetd = ( "/etc/inet/inetd.conf" )
  ftpd = ( "/usr/sbin/in.ftpd" )
  ftpd_base = ( "in.ftpd" )
 osf::
  inetd = ( "/etc/inetd.conf" )
  ftpd = ( "/usr/sbin/ftpd" )
  ftpd_base = ( "ftpd" )
editfiles:
 ftp::
  { $(inetd)
    AppendIfNoSuchLine \
     "ftp stream tcp nowait root \
     $(ftpd) $(ftpd_base)"
  }

This works fine, but has two significant drawbacks. These variables are macros, created by hand, and one cannot write a script to discover their values. Variables live in a flat name space, so that repeating this process leads to many variables and much to remember when writing configuration entries.

Using Prolog, one can accomplish the same task somewhat more neatly. First, we code a relation config_path(Name,OS,Path) into Prolog that relates the canonical name of a file with its location in the filesystem. This relation might start, e.g., with the tuples:

config_path(
  'inetd.conf', osf,
  '/etc/inetd.conf').
config_path(
  'inetd.conf', solaris,
  '/etc/inet/inetd.conf').
config_path(
  ftpd, osf,
  '/usr/sbin/ftpd').
config_path(
  ftpd, solaris,
  '/usr/sbin/in.ftpd').

Then, using a functor os/1 that returns the generic name of the current operating system, one can write the rule:

editfiles:-
  os(Os),
  config_path('inetd.conf',Os,Path),
  config_path('ftpd',Os,Ftpd),
  file_base_name(Ftpd,FBase),
  appendIfNoSuchLine(Path,
    [ftp,stream,tcp,nowait,
     root,Ftpd,Fbase]).

config_path(
 'inetd.conf', _, '/etc/inetd.conf'):-
  path_type('/etc/inet/inetd.conf',file),!.
config_path(
 'inetd.conf', _, '/etc/inetd.conf'):-
  path_type('/etc/inetd.conf',file),!.
config_path(
 ftpd, _, '/usr/sbin/ftpd'):-
  path_type('/usr/sbin/ftpd',file),!.
config_path(
  ftpd, _, '/usr/sbin/in.ftpd'):-
  path_type('/usr/sbin/in.ftpd',file),!.
config_path(
  ftpd, _, '/usr/etc/in.ftpd'):-
  path_type('/usr/etc/in.ftpd',file),!.

This does the exact same thing as the Cfengine example, but the Prolog code can be modified to do considerably more. Consider the rules in Listing 1. These rules compute the paths for these files by actively probing the filesystem for their existence This covers all cases without having to hand-code the locations for each operating system, using tests similar to those used by configure and autoconf.

Now let us go to an even higher level of abstraction: we should only do this when ftp is required. First, let's only use the rule when we need that service, by adding a 'guard clause' to the Prolog code:

editfiles:-
  service(ftp),
  os(Os),
  config_path('inetd.conf',Os,Path),
  config_path('ftpd',Os,Ftpd),
  file_base_name(Ftpd,FBase),
  appendIfNoSuchLine(Path,
    [ftp,stream,tcp,nowait,root,
                   Ftpd,Fbase]).

service(ftp):-hostname(monica).
service(ftp):-os(osf).

service(ftp):-not passwd(bgates,
                     _,_,_,_,_,_).

The rule that actually adds the appropriate line to inetd.conf is not part of operating policy. It is a reusable method that works in most cases. The actual policy is embodied, instead, by the rules for service/1. Ideally, we should be able to write the former once and never touch it again, then modify the latter to taste for each site and application.

This represents a major difference between using Prolog and other languages for configuration. Typically, when one gets to a high-enough lingual level to describe policy, low-level details (such as your user database!) become inaccessible. Prolog allows one to craft high-level, service-based policies that utilize data from all facets of the running system.

Configuring High-level Services

While Cfengine does a good job of implementing policies regarding individual files, it is quite awkward to describe how to implement high level services using Cfengine's syntax. Take, for example, the case of setting up an entire FTP server. Everyone knows that there are at least three actions involved in setting up a typical server within a UNIX-like operating system:

• Add an appropriate line to inetd.conf.
• Add appropriate port descriptions to services
• Send a HUP signal to inetd.

In Cfengine, to define ftp on three machines bill, hillary, monica, a mix of Solaris and OSF machines, these actions could be declared as follows:

control:
 solaris::
  inetd = ( "/etc/inet/inetd.conf" )
  ftpd = ( "/usr/sbin/in.ftpd" )
  ftpd_base = ( "in.ftpd" )
  services = ( "/etc/inet/services" )
 osf::
  inetd = ( "/etc/inetd.conf" )
  ftpd = ( "/usr/sbin/ftpd" )
  ftpd_base = ( "ftpd" )
  services = ( "/etc/services" )
groups:
 ftp = ( bill hillary monica )
editfiles:
 ftp::
 { $(inetd)
  AppendIfNoSuchLine \
    "ftp stream tcp nowait root \
     $(ftpd) $(ftpd_base)"
 }
 { $(services)
  AppendIfNoSuchLine "ftp-data 20/tcp"
  AppendIfNoSuchLine "ftp 21/tcp"
 }
processes:
 ftp::
  "inetd" signal=hup

This approach has several advantages. Each action is done at most once, even if needed in several cases, e.g., inetd is only HUP'd once even if several changes are made to inetd.conf. Once ftp configuration is described for each operating system, one need only list the machines that should support it.

But there are several problems with this approach from our perspective. It is difficult to specify parameters that modify implementation, e.g., using TCP wrappers for security [25], passing parameters to daemons, etc. Each variant requires that a new class and/or macro be created, and these exist in a global name space. Actions of each type are done 'all together' with no concept of installing 'one service at a time'. Thus there is no concept of transaction integrity or transaction rollback if necessary for any reason. Variables and classes have global scope, so in every section of the file, we must remember that solaris represents an operating system, while hillary represents a machine name, and we cannot name a machine solaris without serious problems!

How does the same complex example look in Prolog? First, let's list the hosts that should have ftp service in Prolog rules:

service(ftp):-hostname(bill).
service(ftp):-hostname(hillary).
service(ftp):-hostname(monica).

config_path('services',solaris,
            '/etc/inet/services').
config_path('services',osf,
            '/etc/services').

ftp:-
 service(ftp),
 os(Os),
 config_path('inetd.conf',Os,Inetd),
 config_path('ftpd',Os,Ftpd),
 config_path('services',Os,Services),
 file_base_name(Ftpd,FBase),
 appendIfNoSuchLine(Inetd,
  [ftp,stream,tcp,nowait,root,
   Ftpd,Fbase]),
 appendIfNoSuchLine(Services,
  ['ftp-data','20/tcp']),
 appendIfNoSuchLine(Services,
  ['ftp','21/tcp']),
 kill(inetd,hup).

ftp:-
 service(ftp),
 os(Os),
 path('inetd.conf',Os,Inetd),
 path('ftpd',Os,Ftpd),
 path('services',Os,Services),
 file_base_name(Ftpd,FBase),
 deleteLinesContaining(Inetd,Ftpd),
 deleteLinesContaining(Services,
                       '20/tcp'),
 deleteLinesContaining(Services,
                       '21/tcp'),
 kill(inetd,hup).

watch
   members bill hillary monica

#if solaris
fstab    /etc/vfstab
#endif
#if osf
fstab    /etc/fstab
#endif

AnnoyBill
  init
    status active
    level critical
    task "Harass Bill"
    input proc "=w | =grep clinton"
    dat $tty 2
  rule
    exec wait =write \
          clinton $tty < =mesg

annoyBill:-
 os(Os),
 command_path(w,Os,WPath),
 output_tail(WPath,1,Out),
 split(Out,'[ \t][ \t]*',[clinton,Tty|_]),
 command_path(write,Os,WritePath),
 file_path(message,Os,MessPath),
 concat_atom(
   [WritePath,clinton,Tty,
      '<',MessPath],' ',Command),
 system(Command).
?- annoyBill,fail.

w(User,Tty):-
 os(Os),
 command_path(w,Os,WPath),
 output_tail(WPath,1,Out),
 split(Out,'[ \t][ \t]*',[User,Tty|_]).

annoyBill:-
 w(clinton,Tty),
 os(Os),
 command_path(write,Os,WritePath),
 file_path(message,Os,MessPath),
 concat_atom(
   [WritePath,clinton,Tty,'<',
           MessPath],' ',Command),
 system(Command).

annoyBill:-
 w(clinton,Tty),
 file_path(message,Os,MessPath),
 write(clinton,Tty,MessPath).

diff:-
 expand_file_name('*',Nodes),
 member(File1, Nodes),
 member(File2, Nodes),
 concat_atom_chars(['diff',File1,
               File2],' ',Command),
 system(Command).
?- diff,fail.

pair([File1|Rest],File1,File2):-
 member(File2,Rest).
pair([_|Rest],File1,File2):-
 pair(Rest,File1,File2).
diff:-
 expand_file_name('*',Nodes),
 pair(Nodes,File1,File2),
 concat_atom_chars(
  ['diff',File1,File2],
  ' ',Command),
 system(Command).
?- diff,fail.