Install & Configure Elastic Curator for Index Management

After you have set up your ELK Stack and have been using it for a while (see Step-By-Step Install ELK Stack), a question should start creeping into your head; How do I stop my Elasticsearch Indexes from growing endlessly?  Now you could occasionally go into Kibana and delete the indexes via the GUI found there, but we’re sysadmins!  We automate things!  Luckily Elastic has provided a utility for managing indexes named Curator, which is easily ran as a cron job.  Win!  Be sure to visit the Elastic Curator page and get an idea of what you can do with it, and roughly how it is configured.  We are going to configure it to delete all indexes beginning with winlogbeat- and filebeat- that are older than 90 days in this example, so let’s get to setting that up.  I will be showing you the most recent version as of writing this, Curator version 5.5.4.

Installing & Configuring Curator

1.  Start by downloading the DEB package which is hidden on the APT install page.  I usually place these in /tmp for easy cleanup.

2.  Once you have that downloaded, let’s install it.

3.  Curator will now be installed at /opt/elasticsearch-curator, but we don’t want to mess with anything in there.  I created a hidden directory in my home directory named curator as the documentation suggests as default, and then created a configuration file in that directory for Curator.

I placed the following configuration in the curator.yml file.

This is pretty straightforward.  It tells Curator to connect to Elasticsearch found on localhost (127.0.0.1) on port 9200 without SSL and send basic log info to a file at /home/username/.curator/log.log.

4.  Now we need to tell Curator what to do now that it knows what to connect to and what not.  We do this with an action file, which I creatively named action.yml.

I placed the following configuration in the action.yml based off of the example found here in the documentation.

5.  Now we can test it with the –dry-run argument.  This will log what Curator WOULD do if it were not being run with the –dry-run argument, it does not actually perform the actions.

Check the log to see all indexes older than 90 days would have been deleted.

6.  Assuming that all checks out, we just have to make a cron job to run this thing for us.  I like to run it daily, but it’s dealers choice.  Start by making your script in the appropriate directory.

And added the following:

7.  Now we just need to add the actual cronjob.

Append the following to the bottom of the file:

This configures the cronjob to run the curator.sh script that we made in step 6 to run every day at 6am as root.  Curator is now set up to manage your indexes!

Schannel Event 36870 – A fatal error occurred – RDP

Came in one morning to reports that nobody can access a particular Windows Server 2012R2 RDS server.  To keep from being too wordy, I took some time and narrowed it down to just an issue with that one particular server, not RDS itself.  As I kept digging I came across numerous instances of the following Schannel Event 36870 error on the effected RDS host, which I could then reproduce by attempting to make an RDP connection to the server experiencing the issue.

Now this led me down quite a number of SSL certificate rabbit holes, but the winner came from this stackoverflow article, which referenced this Microsoft blog post, in which scenario 2 was my solution.  I restored default permissions to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, restarted the box, and wha-lah!  RDP was functional again!