Quick Tip: Locate the Temporary Password in a MySQL Community Server Installation

I was working on a project at work last week which required me to use the MySQL Community Server distribution of MySQL. This was my first time ever using this variant of MySQL Server, but I didn’t see any fundamental differences between it and more mainstream versions like MariaDB, etc. Unfortunately, I would soon be proven wrong. As I was going through my usual database server deployment checklist, I started the mysql_secure_installation script and was unable to use it to set the password for the root user. This seemed strange to me since, to my knowledge anyway, MySQL shipped with no root password set and relied on the user to set one. Apparently, that’s not the case with MySQL Community Server. Instead, MySQL Community Server generates a temporary password for the root user and applies it during initial start-up. After a bit of Googling I found that the generated password is logged to /var/log/mysqld.log so we can use grep to quickly figure out what it is. To determine the default root password generated by MySQL Community Server during initial start-up run the following command:

Then run mysql_secure_installation and follow the prompts as you normally would.


Automatically Create an OmniFocus Task with AppleScript and BASH

Thanks to the Mac Power Users podcast, I discovered OmniFocus about a year and a half ago and it changed my lifeSeriously. I could (and very well may) write an entire post about my love for OmniFocus, but today I want to talk about mental friction and how I elevated a little of mine. Tools like OmniFocus are great for drastically reducing stress by allowing you to easily get all the stuff in your head into a trusted system, process it and take action on it as needed. If you’re anything like me though you put everything into your system and end up some tasks that, in some cases, repeat daily wether they’re actionable or not. The repeating task that prompted me to figure out how to automatically create an OmniFocus task was “Process action folder”. The concept of the action folder is simple: as things come into your system that need to be dealt with later in the day, they’re moved to the action folder and that folder is processed, well, later that day. I chose to put my action folder on Dropbox and having a universally accessible location where I could drop and continue with whatever I was doing while knowing it would get dealt with later was awesome! That is, until I discovered DevonTHINK.

Continue reading “Automatically Create an OmniFocus Task with AppleScript and BASH”

Send a Slack Message from a SaltStack Reactor State

My current side project at work is more than a little ambitious. In the past, we’ve had servers randomly “fall off” of our FreeIPA environment and stop authenticating for one reason or another and, after fixing what I honestly believe to be every possible client-side issue a FreeIPA-joined server can experience, I decided there had to be a better way. I’ve always been a huge fan of automation so I wanted a way to automatically detect a server that was failing to authenticate and fix it without any intervention on my part. I started with the quintessential Linux-based automation technology: shell scripting, but I ultimately ended up designing a solution based on SaltStack and SaltStack Reactors. While not yet complete, a few useful learnings have come out of my development work thus far. The learning we’re discussing today is, of course, sending a Slack message from a SaltStack Reactor State.

We aren’t technically a DevOps shop, but we’re steadily introducing more and more DevOps oriented tools and techniques, not the least of which is Slack. We love Slack and use it for team communication as well as alerting from Rundeck jobs so it made sense to send alerts from our Salt states to Slack as well. In my use case I wanted to send three different alerts: a start alert, a success alert or a failure alert. In today’s post, we’ll be looking at how to send the start notification, but the only thing that differs in the other two alerts is the message content. Let’s examine the code that makes this happen:

1. send_start_notification_to_slack_channel: – This line is the ID declaration and can be any unique string you choose.

2. local.slack.post_message: – This line declares the slack.post_message state. Notice local at the beginning of the line, local instructs the Minion running this Reactor State to run the slack.post_message state locally.

3. tgt: {{ data[‘id’] }} – This line sets the target for this state as the id of the Minion running this Reactor.

4. arg: – This line simply begins the list of arguments to the state.

5. #non-prod-alerts – This line indicates the Slack channel name to send the message to. Replace this with a channel in your team.

6. This is a test message sent by {{ data[‘id’] }} and brought to you by SaltStack. – This line contains the actual message body and can be any string you like. Notice that we use {{ data[‘id’] }} again in the middle of the string. {{ data[‘id’] }} will be replaced with the ID of the Minion running this Reactor so if, for example, server1.example.com ran this Reactor State the resulting message would read “This is a test message sent by server1.example.com and brought to you by SaltStack.”

7. saltstack – This line defines the username that will appear to be sending these messages. Replace this with a username that suits your needs.

8. <slack_API_key_goes_here> – Much as the description implies, your Slack API key goes here. Replace this placeholder with your Slack API key.

Whenever a Minion sends a correctly tagged event to the Master and the state is triggered, a message similar to the one shown below will be sent to the designated Slack channel.

That’s all there is to it! With a mere eight lines of code you’ve enabled your Salt Reactor States (and configuration states with a few minor changes) to notify your or your entire team via Slack. This could provide super useful as a way to notify someone when a long running state has completed or even function as a “poor man’s” monitoring system. In a future post I’ll bring the concept of Reactor States full-circle and discuss how to trigger them from Minions, but for now you can continue your salty foray into DevOps by reading over the Salt.States.Slack documentation.

— J