|
| 1 | +--- |
| 2 | +layout: default |
| 3 | +title: "Setting Up an OpenVox Server" |
| 4 | +--- |
| 5 | + |
| 6 | +Using `puppet apply` is great for standalone work, but the real power of OpenVox comes from the agent-server architecture, where one or more OpenVox servers compile catalogs for all your nodes. |
| 7 | +If you'd like to try it out, then we'll set up a server and connect our agent. |
| 8 | + |
| 9 | +**What you'll learn:** |
| 10 | + |
| 11 | +* [Setting up an OpenVox Server](#server-installation) |
| 12 | +* [Managing something with your new server](#managing-something-with-your-new-server) |
| 13 | +* [Where to go next](#next-steps) |
| 14 | + |
| 15 | + |
| 16 | +## Prerequisites |
| 17 | + |
| 18 | +Before we dive in, you'll need: |
| 19 | + |
| 20 | +* The machine you already set up with the OpenVox agent |
| 21 | +* A Linux machine for the OpenVox server |
| 22 | +* Root or `sudo` access |
| 23 | +* Internet connectivity (to reach the package repos) |
| 24 | +* A healthy sense of adventure |
| 25 | + |
| 26 | +{% include alert.html type="tip" title="Pro tip" content="The OpenVox server currently supports only Linux platforms rather than everything that the agent runs on." %} |
| 27 | + |
| 28 | +## Server Installation |
| 29 | + |
| 30 | +We're going to use two nodes for this testing infrastructure; the agent you already built and a server node. |
| 31 | +It's possible to run both on the same node (and most server nodes do indeed also run the agent to self-manage), but doing so makes it easy to slip up and accidentally write code that requires local filesystem access. |
| 32 | + |
| 33 | +Read carefully to see which node the instructions are meant to run on; we'll switch back and forth a few times. |
| 34 | + |
| 35 | +### *[Server Node]* Installation |
| 36 | + |
| 37 | +Install the server on a Linux machine following the [installation guide](/openvox-server/latest/install_from_packages.html). |
| 38 | +This will require you to install a supported JDK, and configure or validate firewall and network settings. |
| 39 | +Make sure to complete all the pre-install tasks **prior to installation**; it can be fiddly to recover an in-progress failed install. |
| 40 | + |
| 41 | + |
| 42 | +### *[Agent Node]* Connecting the Agent |
| 43 | + |
| 44 | +You already have an agent installed. |
| 45 | +Now let's configure it to connect to the server. |
| 46 | + |
| 47 | +```console |
| 48 | +sudo puppet config set server your-openvox-server.example.com --section agent |
| 49 | +``` |
| 50 | + |
| 51 | +Now we'll generate and sign certificates so that your nodes can communicate securely. |
| 52 | +Depending on what you've experimented with, you may have already unknowingly created certificates, so we'll just reset the whole SSL directory to start fresh. |
| 53 | +In regular operation, you'll rarely need to do this. |
| 54 | + |
| 55 | +```console |
| 56 | +sudo rm -rf /opt/puppetlabs/puppet/ssl |
| 57 | +``` |
| 58 | + |
| 59 | +Now we'll run the agent once to generate and request a certificate: |
| 60 | + |
| 61 | +```console |
| 62 | +sudo puppet agent -t |
| 63 | +``` |
| 64 | + |
| 65 | +You'll see something like this. |
| 66 | +If you don't see the certificate generation then go back to the previous step to reset the SSL directory and try again. |
| 67 | +The name printed in this output is known as the `certname` and is the infrastructure-wide identifier for this node. |
| 68 | +By default, it's the same as your hostname. |
| 69 | + |
| 70 | +```console |
| 71 | +$ sudo puppet agent -t |
| 72 | +Info: Creating a new RSA SSL key for agent1.example.com |
| 73 | +Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml |
| 74 | +Info: Creating a new SSL certificate request for agent1.example.com |
| 75 | +Info: Certificate Request fingerprint (SHA256): AB:CD:12:34:... |
| 76 | +Exiting; no certificate found and waitforcert is disabled |
| 77 | +``` |
| 78 | + |
| 79 | +### *[Server Node]* Sign the Certificate |
| 80 | + |
| 81 | +See the outstanding certificate signing requests: |
| 82 | + |
| 83 | +```console |
| 84 | +sudo puppetserver ca list |
| 85 | +``` |
| 86 | + |
| 87 | +Sign the agent's certificate, using the same name as shown in the list: |
| 88 | + |
| 89 | +```console |
| 90 | +sudo puppetserver ca sign --certname agent1.example.com |
| 91 | +``` |
| 92 | + |
| 93 | +Or sign all pending requests: |
| 94 | + |
| 95 | +```console |
| 96 | +sudo puppetserver ca sign --all |
| 97 | +``` |
| 98 | + |
| 99 | +### *[Agent Node]* Install the Certificate |
| 100 | + |
| 101 | +Run the agent again to download and install the freshly signed certificates: |
| 102 | + |
| 103 | +```console |
| 104 | +$ sudo puppet agent -t |
| 105 | +Info: Refreshing CA certificate |
| 106 | +Info: CA certificate is unmodified, using existing CA certificate |
| 107 | +Info: Refreshing CRL |
| 108 | +Info: CRL is unmodified, using existing CRL |
| 109 | +Info: Using environment 'production' |
| 110 | +Info: Retrieving pluginfacts |
| 111 | +Info: Retrieving plugin |
| 112 | +Info: Loading facts |
| 113 | +Notice: Requesting catalog from puppet.example.com:8140 (192.168.1.100) |
| 114 | +Notice: Catalog compiled by puppet.example.com |
| 115 | +Info: Applying configuration version 'openvox-production-719ab13e0a1' |
| 116 | +Notice: Applied catalog in 2.55 seconds |
| 117 | +``` |
| 118 | + |
| 119 | +{% include alert.html type="tip" title="Pro tip" content="The `-t` flag (short for `--test`) runs the agent in test mode with verbose output and detailed reporting. |
| 120 | +For production runs, the agent daemon (managed by systemd) runs automatically every 30 minutes. |
| 121 | +Use `puppet agent -t --noop` for a dry-run that shows what *would* change without actually changing anything. |
| 122 | +This is invaluable for CI/CD pipelines and change reviews." %} |
| 123 | + |
| 124 | +This time it should successfully connect, download its (empty) catalog, and apply it. |
| 125 | +You're in business! |
| 126 | + |
| 127 | + |
| 128 | +## Managing Something With Your New Server |
| 129 | + |
| 130 | +You've now got a fully functional OpenVox server managing an infrastructure made up of a single agent. |
| 131 | +It's not yet really doing much though, since you haven't defined any configuration for your infrastructure. |
| 132 | +Let's write some! |
| 133 | + |
| 134 | +### *[Server Node]* Create a main site manifest |
| 135 | + |
| 136 | +The OpenVox server always starts compiling with a single starting point, no matter which node it is compiling for. |
| 137 | +This is called the *main manifest* or *site manifest* and you can read about [more advanced usage](/openvox/latest/dirs_manifest.html) in the docs. |
| 138 | + |
| 139 | +Let's create a site manifest that will ensure that all nodes are enforcing configuration regularly. |
| 140 | +We'll also add a bit of configuration for specific nodes. |
| 141 | + |
| 142 | +Edit the file `/etc/puppetlabs/code/environments/production/manifests/site.pp`, creating it and any directory structure as needed. |
| 143 | + |
| 144 | +```puppet |
| 145 | +# global configuration that applies unconditionally to all nodes |
| 146 | +service { 'puppet': |
| 147 | + ensure => running, # ensure it's currently running |
| 148 | + enable => true, # and will start at system bootup |
| 149 | +} |
| 150 | +
|
| 151 | +node 'agent1.example.com' { |
| 152 | + file { '/tmp/hello-openvox.txt': |
| 153 | + ensure => file, |
| 154 | + content => "Hello from OpenVox! 🦊\nThis node is managed by an OpenVox server.\n", |
| 155 | + mode => '0644', |
| 156 | + } |
| 157 | +} |
| 158 | +
|
| 159 | +node default { |
| 160 | + notify { 'welcome_message': |
| 161 | + message => This node is managed by an OpenVox server, but has no configuration defined.', |
| 162 | + } |
| 163 | +} |
| 164 | +``` |
| 165 | + |
| 166 | +### *[Agent Node]* Enforce configuration |
| 167 | + |
| 168 | +From now on, all you do on the agent node is trigger an OpenVox run and validate that it did what you want. |
| 169 | +After the `puppet` service is enabled, it will continue to *converge* to the desired state every 30 minutes. |
| 170 | + |
| 171 | +```console |
| 172 | +$ sudo puppet agent -t |
| 173 | +Info: Using environment 'production' |
| 174 | +Info: Retrieving pluginfacts |
| 175 | +Info: Retrieving plugin |
| 176 | +Info: Loading facts |
| 177 | +Notice: Requesting catalog from puppet.example.com:8140 (192.168.1.100) |
| 178 | +Notice: Catalog compiled by puppet.example.com |
| 179 | +Info: Caching catalog for agent1.example.com |
| 180 | +Info: Applying configuration version '1778625673' |
| 181 | +Notice: /Stage[main]/Main/Service[puppet]/ensure: ensure changed 'stopped' to 'running' |
| 182 | +Info: /Stage[main]/Main/Service[puppet]: Unscheduling refresh on Service[puppet] |
| 183 | +Notice: Applied catalog in 2.27 seconds |
| 184 | +``` |
| 185 | + |
| 186 | +{% include alert.html type="tip" title="Pro tip" content="The `-t` or `--test` flag is named this way because in regular use you won't *push* configuration to your agent nodes. |
| 187 | +You'll just let them retrieve and enforce configuration on their regular schedule. |
| 188 | +The `test` mode lets you interactively observe the results of new configuration you've written." %} |
| 189 | + |
| 190 | +## Next Steps |
| 191 | + |
| 192 | +* Dive a little deeper into how the whole [OpenVox infrastructure is architected](architecture.html). |
| 193 | +* Learn a bit more about the [Puppet Language](language.html) and classifying nodes. |
0 commit comments