#52 – Vagabond and Rundeck w/ JR Bing

This week on the podcast we celebrate 1 year of podcasting with JR Bing. JR talked with us about his Vagabond project for managing PeopleSoft Images, how he uses RunDeck to simplify daily administration tasks, being a Mac user and using GitHub to manage projects and code.

We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at podcast@psadmin.io, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.

You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.

Podcast RSS Feed

Show Notes

Encrypt psft_customizations.yaml Passwords

In the psft_customizations.yaml file we store configuration information for a server, including passwords. There is a project, hiera-eyaml, that supports encrypting and decrypting sensitive data in Hiera YAML files. Out of the box, the Windows-based DPK doesn’t work with hiera-eyaml. For Linux DPK, check out 2188771.1 – there is better support in the Linux DPK for hiera-eyaml.

In this post, we’ll walk through the steps to get hiera-eyaml working on Windows and how to encrypt data in the psft_customizations.yaml file.

Update RubyGems

The version of Ruby, and RubyGems, that ships with the DPK can’t install new Gems. The RubyGems version doesn’t support trust the site’s SSL certificate. To fix that, download the root certificate and tell RubyGems to trust it.

  1. Download the newer SSL certificate.
  2. Save the file as RubyGemsRootCA.pem
  3. Copy the new certificate to C:\Program Files\Puppet Labs\Puppet\sys\ruby\lib\ruby\2.0.0\rubygems\ssl_certs

Copying the new certificate to ssl_certs will tell RubyGems to trust any certificate signed by it. Now we can use RubyGems to install hiera-eyaml on the server.

Install hiera-eyaml

When Puppet is installed, it includes Ruby and RubyGems binaries because Puppet is written in Ruby. We’ll use the gem utility to install the hiera-eyaml RubyGem. First, we should update PATH to include Puppet’s Ruby binaries:

  1. $env:PATH += ";C:\Program Files\Puppet Labs\Puppet\sys\ruby\bin"
  2. gem install hiera-eyaml

RubyGems will install any dependencies and report the progress.

Fetching: trollop-2.1.2.gem (100%)
Successfully installed trollop-2.1.2
Fetching: highline-1.6.21.gem (100%)
Successfully installed highline-1.6.21
Fetching: hiera-eyaml-2.1.0.gem (100%)
Successfully installed hiera-eyaml-2.1.0
Parsing documentation for trollop-2.1.2
Installing ri documentation for trollop-2.1.2
Parsing documentation for highline-1.6.21
Installing ri documentation for highline-1.6.21
Parsing documentation for hiera-eyaml-2.1.0
Installing ri documentation for hiera-eyaml-2.1.0
3 gems installed

Keys

Hiera-eyaml uses it’s own Public and Private keys to encrypt and decrypt data. If you have inspected the puppet\ssl directory, you will see folders for public and private keys. These keys are used by Puppet to communicate with a Puppet Server. We use different keys for encrypting data in psft_customizations.yaml.

The keys should be created in the folder C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\. To ensure the keys are created in the correct location, Hiera-eyaml and Hiera know where they are, we’ll create a configuration file for Hiera-eyaml.

  1. Create eyaml.yaml under C:\ProgramData\PuppetLabs\hiera\etc and add these values:

    ---    
    pkcs7_private_key: C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\private_key.pkcs7.pem  
    pkcs7_public_key: C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\public_key.pkcs7.pem
    
  2. Set the EYAML_CONFIG environment variable:

    $env:EYAML_CONFIG="C:\ProgramData\PuppetLabs\hiera\etc\eyaml.yaml"
    
  3. Create new encryption keys for Hiera-eyaml to use:

    eyaml createkeys
    

Keep these new keys safe and locked down; they decrypt your passwords!

Encrypt Passwords

Now that we have installed Hiera-eyaml and created keys, let’s do a quick test to make sure we can encrypt passwords. This test will encrypt the text “VP1”:

eyaml encrypt -s VP1

The output will look similar to this:

string: ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEALsKtTfAXyHyE/k5r2U2ZZU98SqaQ5/ukfNR/FkOt9bNhoZ1EomqmqIc/06l7Tk5W4BYJA0mXV6ykLgOHYTAJbVPM8gXBuHsw1jh+/VC0er7evlzqtf7UjIvu3rTo+0LUm2X3imjbWHGhyrs2bxm0L1qpC2atlTSzEYrSc6OxkTpZA19Y8iEJxFb+F0fGwsQ3SRVJD1J3Jwf0hAsHN/SXX/p2ywn5qz2BnlJl4wa7ragYv4aVBGbGF3ThvYMCTzNiFHtyHdCFvPX9i/t0fpDUJY76ndAl/T4q/Stopnq6Gm9vLJH5EC6KMUQZzb0ssDHriojQgUH7uFt8/Wn9vFeTQTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBFcUOesdHoJgYi5PnXGmkAgBDbEJsr/tDXbDpJu7+xz9uL]

OR

block: >
    ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw
    DQYJKoZIhvcNAQEBBQAEggEALsKtTfAXyHyE/k5r2U2ZZU98SqaQ5/ukfNR/
    FkOt9bNhoZ1EomqmqIc/06l7Tk5W4BYJA0mXV6ykLgOHYTAJbVPM8gXBuHsw
    1jh+/VC0er7evlzqtf7UjIvu3rTo+0LUm2X3imjbWHGhyrs2bxm0L1qpC2at
    lTSzEYrSc6OxkTpZA19Y8iEJxFb+F0fGwsQ3SRVJD1J3Jwf0hAsHN/SXX/p2
    ywn5qz2BnlJl4wa7ragYv4aVBGbGF3ThvYMCTzNiFHtyHdCFvPX9i/t0fpDU
    JY76ndAl/T4q/Stopnq6Gm9vLJH5EC6KMUQZzb0ssDHriojQgUH7uFt8/Wn9
    vFeTQTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBFcUOesdHoJgYi5PnX
    GmkAgBDbEJsr/tDXbDpJu7+xz9uL]

Hiera-eyaml gives two options for output: string and block. For psft_customizations.yaml I’m using the string output. It’s cleaner and easier to insert into the file. We can request string output only and assign a label to the encrypted password:

eyaml encrypt -s VP1 -o string -q -l db_user_pwd

The output should look like this:

db_user_pwd: ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAV2y+yriBfuFlXspBIzZ8eBEOow7FU7mcwYL1HCpHd+XrwIliMTgDj+4X47XXQ3bce4WRvaezHUNahJQF4OZrwlGdCgXYeFG4dYvMEg/75T0704I2+y/XmLpI3Y5swd3L9LnHfxpAm6x8AJpf2yybSP4rsD1IxZgrpjy1CjFe3GuRW9ZcNFkNq5WofRweoX4C9QgNp1bmXQnJym+ZnVe1y7vQ9iEY336vF2FH3wJNgqRIy+74RWj9F+OaAg78meSxM0eM7jm4fLa32cMmOLzfU/FGFhLFcQJ2FaAa5/SWmBSgtwDUXsGaLcSa0R2nfQZrbRWmlP+s1WYL9MzkLFTEoDA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBDMAfrBMvJ+HRA+iL4zyQppgBBcHlLe8hUl6JD1jFXH/N22]

We can pass the output of this command into the clipboard and then paste the line directly into psft_customizations.yaml:

eyaml encrypt -s VP1 -o string -q -l db_user_pwd | set-clipboard

set-clipboard requires WMF 5.0

Edit YAML Files

Encrypting passwords on the command line is great, but what if you want to edit all of the passwords in your psft_customizations.yaml file at once? Hiera-eyaml has an edit command that will decrypt the passwords in psft_customizations.yaml and open the file in a text editor for you. First, we need to set the EDITOR environment variable:

  1. $env:EDITOR="notepad.exe"
  2. eyaml edit .\psft_customizations.yaml

Notepad will open the psft_customizations.yaml file. At the top of the file, you will see a large comment block explaining how to add and edit passwords. (The comment block will go away when you close Notepad.)

Add New Passwords

To add a new password, you wrap the plain text password inside the brackets in this syntax: DEC::PKCS7[plaintextpassword]! For example,

db_user_pwd:     DEC::PKCS7[VP1]!

If you save and close the file, and open psft_customizations.yaml directly in Notepad, you will see the db_user_pwd: password is encrypted.

db_user_pwd:  ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAdGWx7WeuGw3lULsdDANpYotX66B1wzO3U9H47RLJA+s4cIVg5z2JtzTp+uHOp9L9SdcNyzsvo6+uPY29DxMsaIUv9Dfa5LWKv+GZypH4myJYxbNfhtRE5TcLWxxwTSji9WYxDyFu8FFJGIkdNcEzN4svG6CknDhmA/od/NPanQg+xWbjP2qJkiOMi2fDwPJd11dev7Qm4NcwkZzdcsMBpkSgL3eL2dZ/BzdJndWrsGlYfUAy0TLxJD9a4aBCiwYoWWmmS4smnmtmti0R1DPEs8BpAl5L76JItMUwzRsnmu5IZ8odxn8rQZQNJaOVk/oScp4SRIgCh5+tYp7FMvgM/jA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCqrQ+GokeF23Of2odDkv5JgBBulnH4XkLOrQBEy+fa7cMr]

Excellent – we have encrypted passwords!

Edit Passwords

The next step is to edit existing encrypted passwords in the psft_customizations.yaml file. The eyaml edit command will open the file and decrypt passwords. The password syntax will be slightly different – it will have a number assigned to the password: db_user_pwd: DEC(1)::PKCS7[VP1]!

The (1) is used internally by Hiera-eyaml, so don’t change it. But you can change the password inside the square brackets. After changing the password, save and close the file and your updated passwords will be encrypted.

Enable eyaml with the DPK

When we push psft_customizations.yaml out to servers, we also need to ensure each server has the keys used to encrypt the passwords, and also knows about Hiera-eyaml. First, if you are using the encrypted passwords on more than one server, copy the puppet\etc\secure\keys folder to each server.

Next, Hiera needs to know that we are using Hiera-eyaml. In C:\ProgramData\PuppetLabs\hiera\etc\hiera.yaml, enable eyaml as a back-end format by adding - eyaml to the ;backends: section:

:backends:
    - yaml
    - eyaml

Verify that the :eyaml: section is at the bottom of hiera.yaml. Change the paths to the Public and Private keys. If you followed the steps above and created them in puppet\etc\secure\keys, the paths will look like this:

:eyaml:
    :datadir: C:\ProgramData\PuppetLabs\puppet\etc\data
    :extension: yaml

    :pkcs7_private_key: C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\private_key.pkcs7.pem
    :pkcs7_public_key:  C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\public_key.pkcs7.pem

Save hiera.yaml and let’s test our configuration.

Testing Hiera-eyaml

To test Hiera-eyaml and Puppet working together, we’ll encrypt the a password in psft_customizations.yaml and update UserPswd= value in psappsrv.cfg.

  1. Open psft_customizations.yaml with eyaml edit and add the line:

    db_user_pwd: DEC::PKCS7[VP1]!
    
  2. Save and close psft_customizations.yaml.

  3. Save this code below as pwd.pp and save it to puppet\etc\manifests. Change the $configFile path to point to your psappsrv.cfg file.

    $configFile = 'C:/Users/vagrant/psft/pt/8.55/appserv/APPDOM/psappsrv.cfg' 
    ini_setting { "eyaml_test": 
        ensure => present, 
        path => $configFile, 
        section => 'Startup', 
        setting => 'UserPswd', 
        value => hiera('db_user_pwd'), 
    }
    
  4. Change directories to puppet\etc\manifests.

  5. Run puppet apply .\pwd.pp --trace --debug

  6. After the run is done, open your psappsrv.cfg file. You should see UserPswd=VP1 in the file.

If the test above worked, you’re all set to use Hiera-eyaml with the DPK and Puppet. Once Hiera knows about Hiera-eyaml, any data in Hiera can be encrypted. Happy encrypting!

#51 – Elastic{on}

This week on the podcast, Kyle and Dan record from the Elastic{on} Conference in Chicago. We attended the conference to learn more about Elasticsearch and the Elastic platform. The tl;dr, we are excited about the future of the Elasticsearch and the Elastic ecosystem. We also talk about purging log files, Change Assistant and passwords, and sharing PSPing results.

We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at podcast@psadmin.io, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.

You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.

Podcast RSS Feed

Show Notes

  • Windows 2016 is Out @ 1:00
  • PSPing Results @ 2:45
  • Extract Data Mover DML Statements @ 4:30
  • Wiki to OneNote @ 6:45
    • Control-Enter will create a new row in a OneNote table
  • Change Assistant and Passwords @ 16:00
  • Vagrant Introduction @ 20:45
  • How do you do it? Purging Log Files @ 23:15
  • Elastic{on} Recap @ 28:15
    • Expanding on Elasticsearch with PeopleSoft @ 41:00

#50 – Oracle Enterprise Manager

This week on the podcast, Kyle gives a great overview Enterprise Manager and how he is using it for database refreshes and more. Dan and Kyle also discuss PeopleCode formatting, how they manage the xdo.cfg file and fixing CORS issues in PeopleTools 8.55.

We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at podcast@psadmin.io, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.

You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.

Podcast RSS Feed

Show Notes

Enable Tuxedo Domain Features with the DPK

Since the DPK was released, there has a been a bug (for Windows) that is quite annoying. In the psft_customizations.yaml file, the feature_settings: section is supposed to turn Tuxedo domain features on or off.

feature_settings:
  PUBSUB:           "Yes"
  QUICKSRV:         "No"
  QUERYSRV:         "Yes"
  JOLT:             "Yes"

On Windows, these settings were ignored and the default values were used when a domain was created or reconfigured. Thanks to Dale Haman from the psadmin.io Community, we have a fix for the bug. The issue is this:

The DPK (Puppet) takes the feature_settings: section in the psft_customizations.yaml file and combines it into a string. The string is passed into psadmin with the -u parameter. The code that creates this string used an incorrect separator for each feature, so psadmin would ignore the entire string.

To fix this, you can edit one file under the puppet/etc/modules folder:

puppet/etc/modules/pt_config/lib/puppet/provider/psftdomain.rb

if Facter.value(:osfamily) == 'windows'
  # feature_settings_separator = '#'
  # For Windows, we need to use the slash
  feature_settings_separator = '/'
else
  feature_settings_separator = '%'
end

If you re-run puppet apply .\site.pp, your app server and process scheduler domains features should match what you defined in psft_customizations.yaml.

Process Scheduler Features

After testing this on a process scheduler, I noticed my scheduler had 5 features listed in psadmin but only two were configured in my psft_customizations.yaml file: MSTRSRV and APPENG. I wanted to configure the other features in the domain, so I added them to my psft_customizations.yaml file:

feature_settings:
  MSTRSRV:          "Yes"
  APPENG:           "No"
  PPM:              "No"
  DOMAIN_GW:        "No"
  SERVER_EVENTS:    "No"

If you run puppet apply .\site.pp with these parameters in your psft_customizations.yaml file, you’ll get an error saying the Feature List is not valid. The feature_settings: section is compared to an array in the Process Scheduler Puppet Type to make sure you don’t mis-type anything, or try to add a non-existent feature. But in this case, the validation array was incorrect. It was missing the "PPM" feature.

puppet/etc/modules/pt_config/lib/puppet/type/pt_prcs_domain.rb

prcs_features =
  # [ "MSTRSRV", "APPENG", "KIOSK", "DOMAIN_GW", "SERVER_EVENTS" ]
  # Add PPM because it is a scheduler feature...KIOSK is not.
  [ "MSTRSRV", "APPENG", "PPM", "DOMAIN_GW", "SERVER_EVENTS"]

Comment out the bad line and change "KIOSK" to "PPM" in the array. Now, you can configure all 5 process scheduler features from the psft_customizations.yaml file.

Check out the other bug fixes for the DPK too:

#49 – Chocolatey

This week on the podcast, Kyle and Dan discover why their app server generates unnecessary .tracesql files. Dan talks about the Chocolatey package manager for Windows and the SES Namespace feature, and Kyle has an update on platform changes with PeopleTools.

We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at podcast@psadmin.io, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.

You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.

Podcast RSS Feed

Show Notes

Introduction to Vagrant

 

As an admin, creating and testing new software with virtual machines has made our jobs easier. Using VirtualBox and your computer, we can set up a VM and test anything. With the PeopleSoft Images, we can quickly set up a new demo environment and test new features.

While setting up new virtual machines is easy, it does require many steps like downloading the base image, setting up users, installing software and more. Getting the same base virtual machine every time requires attention to detail and doing the same steps, over and over.

Vagrant

Vagrant is a tool that creates the same virtual machine for you every time. You can use Vagrant to create your own VM, or use someone elses VM. Vagrant also simplifies the creation and management of virtual machines on your computer. Here is an example of how to use Vagrant to start a new Puppet Enterprise server on Centos 6:

vagrant init puppetlabs/centos-6.6-64-puppet
vagrant up

That’s it!

The first command tells Vagrant that we want to create an image from the template puppetlabs/centos-6.6-64-puppet from Puppet Labs. The second command tell Vagrant to start the VM. The vagrant up command will download the base virtual machine file from Vagrant’s Atlas site, start the image in VirtualBox, and do any server configuration once the VM starts.

Providers

Vagrant is a front end to VirtualBox, but it will also work with VMWare, Hyper-V, Amazon Web Services, Docker and more. Using different providers is pretty easy (AWS takes a little more setup), and Vagrant handles each providers system for you. We only worry about our Vagrant configuration, not the platform our virtual machines are running on. For this post, and others, we’ll stick to VirtualBox since it’s a free option and works on multiple operating systems.

Atlas

Atlas is service from Vagrant were you can find virtual machine templates created by community members. On Atlas you can search for an OS or software and find virtual machines that people have created. Some of the popular virtual machines are:

  • hashicorp/precise64 – Ubuntu 12.04 TLS 64-bit
  • centos/7 – Centos 7 64-bit
  • puppetlabs/centos-6.6-64-puppet – Puppet Enterprise on Centos 6.6.64
  • mwrock/Windows2012R2 – Windows 2012 R2 (Evaluation License – 180 days)

Install Vagrant

The first step to using Vagrant is to install the latest build. Go to the Vagrant Downloads page and grab the installer for your platform. Download the installer and run it.

Next we need VirtualBox installed. If you already have it installed, take this time to upgrade to the lastest version. You can download the latest version of VirtualBox here.

Create a Virtual Machine

 

Now we can use Vagrant to create a new virtual machine. Open a command prompt and navigate to the folder where you want to store the virtual machine.

cd ~/VirtualBox VMs/

Next, create a new folder to hold our first virtual machine:

mkdir elastic_test
cd elastic_test

We’ll use the centos/7 base image for our test.

vagrant init centos/7

The init command will create a new file in the folder: Vagrantfile. The Vagrantfile tell Vagrant how to configure the virtual machine. We use this file to give the VM a name, how much memory to use, what networking type, and more. We’ll come back to file later.

The next step is to start the virtual machine.

vagrant up

The up command does a few things:

  1. Checks to see if you have VM on the system
  2. If not, download the image from Atlas
  3. Start the VM in VirtualBox (headless VM)
  4. Configure port forwarding and connect to the VM with SSH
  5. Set up the Vagrant share
  6. Run any provisioning scripts in the VM

That one command handles a lot of work for us. Let’s look at some of the key steps.

vagrant Shared Folder

By default, Vagrant will share the folder where you create the virtual machine as /vagrant inside the VM. This share is convenient but is also important for Vagrant provisioning. Script inside the folder, in our case elastic_test, are accessible in the VM. We can configure different folders to share as well. In Vagrantfile, uncomment and modify `

config.vm.synced_folder "../data", "/vagrant_data" 

to point to the folder on your host you want to share. The next time you start the virtual machine the share will be configured.

Vagrant ssh

For Linux virtual machines, SSH is configured when the VM is created. To access the virtual machine via SSH, use

vagrant ssh

You can use traditional ssh commands, but using vagrant ssh will use pre-configured SSH keys and log you into the VM.

Port Forwarding and Networking

By default, Vagrant will set up the virtual machine to use a private IP address. This means you can only access the VM from the host machine. When the VM is created, port 2222 is configured to forward requests to port 22 (for SSH). vagrant ssh knows this, so it connects to localhost:2222 when you connect to the VM. To change the networking configuration so anyone on your network can access the VM, update this line in Vagrantfile:

config.vm.network "public_network"

Vagrant will create a second network adapter that grabs a public IP from your networks DHCP server.

Memory and More

The last change we’ll make to the virtual machine is setting the memory and enabling the GUI. When Vagrant starts a Linux VM, it starts a Headless session (no GUI window). If you are comfortable with SSH and command lines this won’t be an issue. If you want to see the VM window in VirtualBox, we’ll update the Vagrantfile to show the GUI.

  config.vm.provider "virtualbox" do |vb|
    # Display the VirtualBox GUI when booting the machine
    vb.gui = true

    # Customize the amount of memory on the VM:
    vb.memory = "1024"
  end

For Windows virtual machines, except Windows Server Core/Nano, the GUI will display by default.

Restart, Shutdown and Delete VM’s

To restart or stop a virtual machine created by Vagrant, we use these commands:

  • Restart: vagrant reload
  • Shutdown: vagrant halt

If you are done with the virtual machine and want it removed from your system, use:

vagrant destroy

Provisioning

 

Those are the basics to using Vagrant. Once you spend a few minutes working with Vagrant, it is hard to go back to creating virtual machines by hand. But quickly creating VM’s is only one benefit of Vagrant. Vagrant has an excellent provisioning mechanism, which means you can create the same VM every time.

Let’s install Elasticsearch in our virtual machine. In the Vagrantfile, find the section config.vm.provision and update it:

config.vm.provision "shell", inline: <<-SHELL
  sudo yum install wget -y
  sudo yum install java -y
  sudo rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch
  sudo wget https://gist.githubusercontent.com/iversond/a5d8985657a9a6c4332dd9a776bd195a/raw/88d3b1b3eb14a4f638ce07473550d108287e4e7e/yum-elasticsearch.repo -O /etc/yum.repos.d/elasticsearch.repo
  sudo yum install elasticsearch -y
  sudo systemctl daemon-reload
  sudo systemctl enable elasticsearch.service
  sudo systemctl start elasticsearch.service
SHELL

Vagrant will run the provisioning script the first time a virtual machine is created, but we can re-run provisioning at any time. Run the command:

vagrant provision

After the provisioning scripts run, log into the virtual machine and check if Elasticsearch is running.

vagrant SSH
curl -X GET http://localhost:9200/

If Elasticsearch installed correctly, you’ll see a response like this:

{
  "name" : "Talia Josephine Wagner",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "x1W8bOqBTEy8rdR0P6VUwg",
  "version" : {
    "number" : "2.4.1",
    "build_hash" : "c67dc32e24162035d18d6fe1e952c4cbcbe79d16",
    "build_timestamp" : "2016-09-27T18:57:55Z",
    "build_snapshot" : false,
    "lucene_version" : "5.5.2"
  },
  "tagline" : "You Know, for Search"
}

Disposable and Consistent VM’s

Let’s say we messed up our VM by accidentally running a bad command, or updated some software that messed up our configuration. For example:

rm -rf / --no-preserve-root

Now our virtual machine is broken. Let’s use Vagrant to delete and recreate our VM. We should have the same VM we had before we “accidentally” ran that command.

First step is to shutdown and remove the virtual machine:

vagrant halt
vagrant destroy

If you look at the directory where Vagrant stored the virtual machine, you’ll see the Vagrantfile still exists, but the virtual machine files are gone. Now let’s recreate our virtual machine:

vagrant up

SSH into our rebuilt VM and test Elasticsearch:

vagrant ssh
curl -X GET http://localhost:9200/

That was easy 🙂 We build, broke, removed and rebuilt a virtual machine with a few commands. If you want to build more complex machines (think DPKs), Vagrant supports Puppet, Ansible and more for provisioning.