Knife Search Negative Query

Are you trying to look for Chef Nodes that don't include a particular result? Do you need to avoid pulling back nodes with specific values but need something more complex than NOT? Fear not, the solution exists! It is not very well documented that I can find so here goes.

I did find a couple of references to what I was looking for in negative queries, which I've linked below. It appears this request was fixed, but I couldn't find the merge with the details of what/how. You have to look very careful on the Chef.io page for knife search. If you look carefully under the "Fuzzy Matching" portion in the "About Operators" section you can find a quick reference to the use of AND and NOT in the same search. Their example is "knife search sample "id:foo AND -id:bar""

Anyway, on to the examples.

Search for any instance that is linux and not in the role [webserver]
knife search node -q "os:linux AND -roles:webserver" -i

If using psearch instead of search
knife psearch node "(NOT (os:linux OR roles:webserver)

Note: These are not the same logical results, it is only to show how to use the NOT syntax with the AND operator.


https://tickets.opscode.com/browse/CHEF-1821
https://docs.chef.io/knife_search.html#about-patterns

Chef Runtime Error Nil:NilClass

Today, an error came up with our Chef environment. The chef-client on new servers was having NoMethodError responses and failing during the chef-client run. 

The problem

The error message was pointing at a particular piece of code that has not given us trouble in the past. That code would look like the code below.

variables({
    :attribute_one => node[:node][:attribute][:one],
    :attribute_two => node[:node][:attribute][:two]
})

Fun fact, in Chef Client 12 the notation above no longer works. This is what is cause the nil:NilClass error. The node[:node][:attribute] values are being resolved to nil. That nil value is then stored in the :attribute_one and :attribute_two which means the value ends as a null method.

The fix

variables({
    :attribute_one => node['node']['attribute']['one'],
    :attribute_two => node['node']['attribute']['two']
})

Nginx 502 Bad Gateway

This morning I awoke to a 502 Bad Gateway error from Nginx. Luckily it was only one user that made me aware of this! The current setup I'm running is Nginx as a proxy for Apache.

To resolve this, I first checked to see if httpd was running. Surprisingly, httpd was not running. I went ahead and did "service httpd restart" and all was good. 

After fixing the issue, I set out to see why it may not have been running. The issue was caused by the httpd being set to stop at boot time. I fixed this by using "chkconfig httpd on" which set it to start at boot time. Also accomplished with "sudo /sbin/chkconfig --add httpd"

Curly Brackets in Chef/Ruby

Surprise, it helps to know the syntax of the language you are writing in.

The issue I ran into this time has to deal with the curly brackets in Ruby. 

Code Example 1

execute 'policy_selinux' do

  command "semodule -i /tmp/policy.pp"

  action :run

  not_if { 'semodule -l | grep policy' }

end

Code Example 2

execute 'policy_selinux' do

  command "semodule -i /tmp/policy.pp"

  action :run

  not_if 'semodule -l | grep policy' 

end

The key to note between example 1 and 2 is that in the second example there is no use of the curly "{}" brackets. This is for a very good reason. The curly brackets, in our case, are being used like a code block. This means that in example 1, the not_if is evaluating the {'semodule -l | grep policy'} as a code block. The code block evaluates as true all the time because it is evaluating a string that has no arguments to evaluate it(tautology). 

The code example 2 has no "{}" which means that the string is going to be used by the not_if statement. This will not be evaluated as a code block, but a string that is truly a command with a return status. This will allow us to get our return status like we desire.

Below is a good resource that helped lead me to my conclusion.
http://stackoverflow.com/questions/12565/what-do-the-different-brackets-in-ruby-mean 

systemd Run In

Well, it finally happened. I ran into systemd. I wasn't looking forward to this experience but it was less frustrating than it could have been. I have been training a new employee who is not experience with Linux. I have been taking them through the initial phases of using Linux by taking them through RHEL.

My first mistake was not understanding the differences between RHEL 6 and RHEL 7. Turns out that RHEL 7 contains the infamous systemd. I had not thought about this when having the new employee follow tutorials from the Internet. Oops...

Issue:

The following command is to enable httpd to start automatically:
sudo systemctl enable httpd.service

The adorable part of this command is that it is specific to operating systems using systemd, in our case RHEL 7. I had not seen this while suggesting tutorials.

Fix:

chkconfig httpd on

This command is the acceptable command for a RHEL 6 system to enable httpd automatically.

Wireshark Columns

Hansang Bae is the man when it comes to Wireshark, IMO. I have listened to many of his videos and his insight is always spot on. Knowing which columns to use in your Wireshark setup can be confusing but the first article linked below does a nice job explaining some tricks to a better environment.

Delta shows the time between packets. Big time, big problem! (At least a good place to start.)
CumuBytes allows us to see how much data is being transferred, cumulatively!

• NxtSEQ
• A counter of how many bytes have been transferred
• custom field type
• field name = tcp.ack
• SEQ
• A helpful reminder that the next time you transmit you’re going to start at this point
• custom field type
• field name = tcp.seq
• ACK
• The receiver sends the ACK, saying they’ve received this many bytes, so you’re good to go to such-and-such packet number
• custom field type
• field name = tcp.ack
• ACKFor
• Quick way to see, for example, packet #11 is ACKing packet #10
• custom field type
• field name = tcp.analysis.acks_frame

Wireshark Column Advice
http://www.riverbednews.com/2014/05/ask-the-experts-top-wireshark-tips-and-tricks-from-bae-and-combs/

Hansang Bae Videos for Developers
http://www.lovemytool.com/blog/hansang-bae/

Chef Idempotence using Grep

Chef is very intuitive, especially when using Opscode and community cookbooks. Typically, the cookbooks from Opscode and the community will be idempotent, one of the main tenants of Chef. Some cookbooks may not include all of the desired functionality and additions, through wrapper cookbooks, may need to be made.

Grep is a key tool for using Linux and can even benefit us when managing Linux machines with Chef. In order to maintain idempotence, we can use grep in our recipes. This allows recipes to only use blocks of ruby when they have not been run before or the state has changed.

In the code below, we want to install the SELinux module called "added_semodule" to the Amazon Linux node from our file /tmp/added_semodule.pp, a reconfigured SELinux module. We do not want to install the module if it has already been installed earlier.

--------------------
case node["platform"]
when "amazon"
execute 'added_semodule' do
  command "semodule -i /tmp/added_semomdule.pp"
  action :run
  not_if 'semodule -l | grep added_semodule'
end
end
--------------------

This example shows how we can test if the module is installed already by listing the installed SELinux modules and using grep to reduce the results to our specific module "added_semodule".