fixing html markup

git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1399 980ebf18-57e1-0310-9a29-db15c13687c0

3 files changed, 89 insertions, 89 deletions

diff --git a/documentation/introduction.page b/documentation/introduction.page
index 5604d5133..837bbb305 100644
--- a/documentation/introduction.page
+++ b/documentation/introduction.page
@@ -23,16 +23,16 @@ contains the configuration for all of your nodes, needs to be on the central
 server, most likely at `/etc/puppet/manifests/site.pp`.
 
 Start the `puppetmasterd` daemon, and then tell your clients to contact that
-server by specifying `-s <servername>` as arguments to `puppetd`,
-replacing "<servername>" with the name of the server.  Alternatively,
-`puppetd` defaults to looking for a server named "puppet", so you can just
-create a CNAME for your server, so that it answers to "puppet".
+server by specifying `-s <servername>` as arguments to `puppetd`,
+replacing ``<servername>`` with the name of the server.  Alternatively,
+`puppetd` defaults to looking for a server named ``puppet``, so you can just
+create a CNAME for your server, so that it answers to ``puppet``.
 
 It is a good idea to run both the server and client in verbose mode, enabled
 with the `-v` flag, until you are sure everything is working.  As each new
 client connects, you will need to run `puppetca --list` to list the
-certificates waiting to be signed, and then `puppetca --sign &lt;name&gt;`,
-replacing "&lt;name&gt;" with the name of the client whose certificate you want to
+certificates waiting to be signed, and then ``puppetca --sign <name>``,
+replacing ``<name>`` with the name of the client whose certificate you want to
 sign.  You can turn on autosigning by creating `/etc/puppet/autosign.conf` and
 put the hosts, domains, or IP addresses or ranges that you want to sign in
 there.
@@ -44,9 +44,9 @@ of actions, action instances, and instance parameters.  Here is how a file
 element would look in puppet:
 
     file { "/etc/passwd":
-        owner =&gt; root,
-        group =&gt; root,
-        mode =&gt; 644
+        owner => root,
+        group => root,
+        mode => 644
     }
 
 Each instance of a low-level element like ``file`` must have a name parameter
@@ -69,16 +69,16 @@ fundamental unit of association is a 'definition':
     # this might change
     define sudo(source,group) {
         package { sudo:
-            version =&gt; "1.6.7"
+            version => "1.6.7"
         }
         file { "/etc/sudoers":
-            source =&gt; $source, # parameterization; copy the file from where?
-            mode =&gt; 440 # the 'file' type converts this appropriately to
+            source => $source, # parameterization; copy the file from where?
+            mode => 440 # the 'file' type converts this appropriately to
                         # octal
         }
         file { "/usr/sbin/sudo":
-            owner =&gt; root,
-            group =&gt; $group
+            owner => root,
+            group => $group
         }
     }
 
@@ -88,8 +88,8 @@ available within the definition itself.
 This definition can now be treated as a type:
 
     sudo {
-        group =&gt; root,
-        source =&gt; "http://fileserver/files/sudoers?v=production"
+        group => root,
+        source => "http://fileserver/files/sudoers?v=production"
     }
 
 One significant difference between definitions and types is that types
@@ -142,7 +142,7 @@ strings don't have be quoted or otherwise marked, but variables must have the
     $group = "root"
 
     file { "/etc/sudoers":
-        group =&gt; $group
+        group => $group
     }
 
 Strings and booleans (``true`` and ``false``) are the only data types; even
@@ -153,8 +153,8 @@ arrays is for implicit iteration:
     $files = ["/etc/passwd","/etc/group","/etc/fstab"]
 
     file { $files:
-        owner =&gt; root,
-        group =&gt; root
+        owner => root,
+        group => root
     }
 
 This implicitly iterates across the file list and performs all of the
@@ -203,9 +203,9 @@ mechanism for this is currently called a 'selector'; it is similar to the
 trinary operator ``:?``:
 
     $value = $variable ? {
-        value1 =&gt; setvalue1,
-        value2 =&gt; setvalue2,
-        default =&gt; other
+        value1 => setvalue1,
+        value2 => setvalue2,
+        default => other
     }
 
 This sets the variable ``$value`` depending on the value of ``$variable``.  If
@@ -214,18 +214,18 @@ gets set to ``other``.
 
 The brackets can be in either part of the expression, or not at all:
 
-    $value = $variable ? "value1" =&gt; "setvalue1"
+    $value = $variable ? "value1" => "setvalue1"
 
 A selector that doesn't match a value is a compile error.
 
 These structures are useful for simplistic abstraction across platforms:
 
     file { "/etc/sudoers":
-        owner =&gt; root,
-        group =&gt; $operatingsystem ? {
-            SunOS =&gt; root,
-            Linux =&gt; root,
-            FreeBSD =&gt; wheel
+        owner => root,
+        group => $operatingsystem ? {
+            SunOS => root,
+            Linux => root,
+            FreeBSD => wheel
         }
     }
 
@@ -265,8 +265,8 @@ types can also have non-state parameters which modify how that type instance
 behaves:
 
     file { "/bin":
-        owner =&gt; bin,
-        recurse =&gt; true
+        owner => bin,
+        recurse => true
     }
 
 The ``recurse`` parameter to ``file`` does not modify the system itself, it
@@ -307,7 +307,7 @@ considered the name:
         isnamevar
     end
 
-With this declaration, ``file { "/tmp/file": }`` is basically equivalent to ``file { path =&gt; "/tmp/file" }``.
+With this declaration, ``file { "/tmp/file": }`` is basically equivalent to ``file { path => "/tmp/file" }``.
 
 See [Creating a Puppet Type](creating-a-puppet-type.html) for more
 information.
diff --git a/documentation/languagetutorial.page b/documentation/languagetutorial.page
index 15d823e61..413176b55 100644
--- a/documentation/languagetutorial.page
+++ b/documentation/languagetutorial.page
@@ -16,9 +16,9 @@ abstraction, selection, and overriding capabilities.
 For simple elements, we just specify the element type, name, and parameters:
 
     file { "/etc/passwd":
-        owner =&gt; root,
-        group =&gt; root,
-        mode =&gt; 644
+        owner => root,
+        group => root,
+        mode => 644
     }
 
 Any machine on which this snippet is executed will use it to verify that the
@@ -31,20 +31,20 @@ For files that vary across systems, it makes sense to create a *symbolic name*
 for your element:
 
     file { sshdconfig:
-        path =&gt; $operatingsystem ? {
-            solaris =&gt; "/usr/local/etc/ssh/sshd_config",
-            default =&gt; "/etc/ssh/sshd_config"
+        path => $operatingsystem ? {
+            solaris => "/usr/local/etc/ssh/sshd_config",
+            default => "/etc/ssh/sshd_config"
         },
-        owner =&gt; root,
-        group =&gt; root,
-        mode =&gt; 644
+        owner => root,
+        group => root,
+        mode => 644
     }
 
 Here we create a symbolic name instead of using the path as the name, and now
 we can refer to that element by name elsewhere in the manifest:
 
     service { sshd:
-        subscribe =&gt; file[sshdconfig]
+        subscribe => file[sshdconfig]
     }
 
 This will cause the ``sshd`` service to get restarted when the ``sshdconfig``
@@ -58,12 +58,12 @@ name, because otherwise the language will assume you are managing separate
 elements, which might result in an error in the library:
 
     file { sshdconfig:
-        path =&gt; "/usr/local/etc/ssh/sshd_config",
-        owner =&gt; root
+        path => "/usr/local/etc/ssh/sshd_config",
+        owner => root
     }
 
     file { "/usr/local/etc/ssh/sshd_config":
-        owner =&gt; sshd
+        owner => sshd
     }
 
 The Puppet parser does not know that these element specifications will attempt
@@ -81,20 +81,20 @@ variable.  This will result in an error:
 
     $user = root
     file { "/etc/passwd":
-        owner =&gt; $user
+        owner => $user
     }
     $user = bin
     file { "/bin":
-        owner =&gt; $user,
-        recurse =&gt; true
+        owner => $user,
+        recurse => true
     }
 
 You will almost always find that you can avoid resetting variable values using
 the builtin [conditionals](structures.html#conditionals):
 
     $group = $operatingsystem ? {
-        solaris =&gt; sysadmin,
-        default =&gt; wheel
+        solaris => sysadmin,
+        default => wheel
     }
 
 This is only one assignment, so no errors.
@@ -106,13 +106,13 @@ trees are created as a manifest is parsed.  Take the following configuration:
 
     class base {
         file { "/etc/issue":
-            source =&gt; "puppet://server/module/common/issue"
+            source => "puppet://server/module/common/issue"
         }
     }
 
     class sub inherits base {
         file { "/etc/issue":
-            source =&gt; "puppet://server/module/mysite/issue"
+            source => "puppet://server/module/mysite/issue"
         }
     }
 
@@ -128,7 +128,7 @@ Puppet elements are normally specified using a lower-case element type.  You
 can specify default values for a given type using the capitalized form of the
 element type, though:
 
-    Exec { path =&gt; "/usr/bin:/bin:/usr/sbin:/sbin" }
+    Exec { path => "/usr/bin:/bin:/usr/sbin:/sbin" }
 
     import "classes/*.pp"
 
@@ -146,7 +146,7 @@ This can be used for any element type.  For instance, CentOS defaults to using
 
     case $operatingsystem {
         centos: {
-            Package { type =&gt; yum }
+            Package { type => yum }
         }
     }
 
diff --git a/documentation/structures.page b/documentation/structures.page
index 9d0c3ff41..8cfc6cd02 100644
--- a/documentation/structures.page
+++ b/documentation/structures.page
@@ -12,8 +12,8 @@ The basic unit of configuration in Puppet are ``types``.  Types model objects
 on the computer being managed, and each builtin type has attributes that
 determine the final type configuration:
 
-    file { "/etc/passwd": owner =&gt; root, mode =&gt; 644 } 
-    package { apache: install =&gt; true }
+    file { "/etc/passwd": owner => root, mode => 644 } 
+    package { apache: install => true }
 
 Puppet also provides facilities for defining new types as collections of
 existing types (see Components below), but there is no syntactic difference
@@ -78,13 +78,13 @@ Functions defined and Classes created within a scope will not be available
 outside the scope in which they are created:
 
     define testing {
-        file { "/etc/passwd": owner =&gt; root }
+        file { "/etc/passwd": owner => root }
     }
 
     class osx {
         # override the existing testing definition
         define testing {
-            file { "/etc/other": owner =&gt; root }
+            file { "/etc/other": owner => root }
         }
     }
 
@@ -96,10 +96,10 @@ of ``/file_repository/test-httpd.conf`` to ``/etc/httpd/conf/httpd.conf``:
     class webserver {
         $filename = "/etc/httpd/conf/httpd.conf"
         define httpd_service (config_file) {
-            file { $filename : source =&gt; $config_file }
+            file { $filename : source => $config_file }
         }
         httpd_service { "test_httpd" : 
-            config_file =&gt; "/file_repository/test-httpd.conf"
+            config_file => "/file_repository/test-httpd.conf"
         }
     }
 
@@ -117,33 +117,33 @@ similarly to variables, by preceding their names with the ``$`` character:
 
     define svnserve(source, path, user = false, password = false) {
         file { $path:
-            create =&gt; directory,
-            owner =&gt; root,
-            group =&gt; root
+            create => directory,
+            owner => root,
+            group => root
         }
         $svncmd = $user ? {
-            false =&gt; "/usr/bin/svn co --non-interactive $source/$name .",
-            default =&gt; "/usr/bin/svn co --non-interactive --username $user --password '$password' $source/$name ."
+            false => "/usr/bin/svn co --non-interactive $source/$name .",
+            default => "/usr/bin/svn co --non-interactive --username $user --password '$password' $source/$name ."
         }   
         exec { $svncmd: 
-            cwd =&gt; $path,
-            require =&gt; file[$path],
-            creates =&gt; "$path/.svn"
+            cwd => $path,
+            require => file[$path],
+            creates => "$path/.svn"
         }   
     }
 
     svnserve { dist:
-        source =&gt; "https://reductivelabs.com/svn",
-        path =&gt; "/dist",
-        user =&gt; "puppet",
-        password =&gt; "password"
+        source => "https://reductivelabs.com/svn",
+        path => "/dist",
+        user => "puppet",
+        password => "password"
     }
 
     svnserve { "dist/config/apps/puppet":
-        source =&gt; "https://reductivelabs.com/svn",
-        path =&gt; "/etc/puppet",
-        user =&gt; "puppet",
-        password =&gt; "password"
+        source => "https://reductivelabs.com/svn",
+        path => "/etc/puppet",
+        user => "puppet",
+        password => "password"
     }
 
 Note that calling components results in a unique instance of all contained
@@ -173,15 +173,15 @@ each of the subclasses.
     # really simple example
     class solaris {
         file {
-            "/etc/passwd": owner =&gt; root, group =&gt; root, mode =&gt; 644;
-            "/etc/shadow": owner =&gt; root, group =&gt; root, mode =&gt; 440
+            "/etc/passwd": owner => root, group => root, mode => 644;
+            "/etc/shadow": owner => root, group => root, mode => 440
         }
     }
 
     class solworkstation inherits solaris {
         file {
-            "/etc/sudoers": owner =&gt; root, group =&gt; root, mode =&gt; 440;
-            "/bin/sudo": owner =&gt; root, group =&gt; root, mode =&gt; 4111
+            "/etc/sudoers": owner => root, group => root, mode => 440;
+            "/bin/sudo": owner => root, group => root, mode => 4111
         }
     }
 
@@ -191,7 +191,7 @@ Because ``include`` is a function, any normal value can be used, including
 variables and selectors:
 
     include $operatingsystem, $hostname ? {
-        myhost =&gt; classA, default classB
+        myhost => classA, default classB
     }
 
 ## Subclassing
@@ -201,15 +201,15 @@ class is that the subclass can override elements in the parent class:
 
     class unix {
         file { "/etc/sudoers":
-            owner =&gt; root,
-            group =&gt; root,
-            mode =&gt; 440
+            owner => root,
+            group => root,
+            mode => 440
         }
     }
 
     class bsd inherits unix {
         file { "/etc/sudoers":
-            group =&gt; wheel
+            group => wheel
         }
     }
 
@@ -257,7 +257,7 @@ code inside will only apply to the specified node or nodes:
     class webserver { ... }
     class dbserver { ... }
 
-    file { "/etc/sudoers": mode =&gt; 440 } # apply to everyone
+    file { "/etc/sudoers": mode => 440 } # apply to everyone
 
     node host1, host2 {
         include webserver
@@ -285,11 +285,11 @@ specify a default value:
 
     define testing(os) {
         owner = $os ? {
-            sunos =&gt; adm,
-            redhat =&gt; bin,
-            default =&gt; root
+            sunos => adm,
+            redhat => bin,
+            default => root
         }
-        file { "/some/file": owner =&gt; $owner }
+        file { "/some/file": owner => $owner }
     }