I have been trying to avoid it for a while. ElasticSearch that is. I have always looked at as far exceeding my needs. Originally there was hope for a hand rolled solution. The honest truth though, is I would rather spend my time on other problems. So I’m just going to roll it out for now.

So on to the repeatable builds! I have been using Salt in my professional engagement recently. Specifically to configure the VMs and VM images. It is a fairly cool system which extends the declarative approach to inside the system. A coworker recently mentioned using it for his personal devices. This is my attempt to do the same.

Packer’s Masterless Provisioner is fairly painless to use. Pretty much point to a local directory, then like magic, it’s transported and applied. I believe Ubuntu has a package. Or least according to their documentation. Works just like the label says! Or at least so far…

To figure out where the salt configuration lives! With the provisioner they lived at /srv/salt however that does not seem to be the case at all. Turns out the first change should be in /etc/salt/minion, setting the variable file_client to local. Next up is to define /srv/salt/top.sls:

base:
  '*':
    - elasticsearch

And elasticsearch

elasticsearch:
  group.present:
    - system: True
  user.present:
    - fullname: ElasticSearch
    - shell: /bin/false
    - home: /srv/elastic/elasticsearch
    - system: True
    - gid: elasticsearch

/srv/elastic:
  file.directory:
    - user: root
    - group: root

/srv/elastic/elasticsearch:
  archive.extracted:
    - source: https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.1-linux-x86_64.tar.gz
    - source_hash: https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.1-linux-x86_64.tar.gz.sha512
    - options: "-v --strip-components=1 -C /srv/elastic/elasticsearch"
    - enforce_toplevel: False
  file.directory:
    - user: elasticsearch
    - group: elasticsearch
    - recurse:
      - user
      - group

/etc/systemd/system/elasticsearch.service:
  file.managed:
    - source: salt://elasticsearch.service
    - user: root
    - group: root
    - mode: 0444
  service.running:
    - name: elasticsearch
    - enable: True
    - reload: True

When I issued OSError: Failed to initialize OpenSSL library (OPENSSL_init_crypto failed) I received an error. Turns out this might be a stale OpenSSL binding for Python. I figured it would be safer to upgrade Salt too, since I had a fairly outdated version:

user@host:> pip3 show salt Name: salt Version: 2017.7.4 Summary: Portable, distributed, remote execution and configuration management system Home-page: http://saltstack.org Author: Thomas S Hatch Author-email: thatch45@gmail.com License: Apache Software License 2.0 Location: /usr/lib/python3/dist-packages Requires:

A quick pip3 install -U salt and…it explodes with an error in my file plus a msgpack warning. Well, progress I suppose. Because I had a legitimate error in my file. Ten points to Hufflepuff! I thought the command going dark while running was an artifact of the Packer interactions. Turns out it just does not tell you anything. Probably better to run it with -l debug from now on.

And that worked! Awesome.