Tuesday, December 16, 2014

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.

Thursday, October 9, 2014

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/

Tuesday, September 16, 2014

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".

Monday, September 8, 2014

Chef Client Debug

The errors returned by Chef are not always the most useful when the error occurs in the operating system rather than in the Chef client. Sometimes we just need more info on what the Chef Client is doing. Give "chef-client -l debug" a try. This should give you all the info you will ever need about your chef client run.

There are additional log levels when running the Chef client besides debug. Those levels include info, warn, error, and fatal. You can try the different levels to get different information back from the Chef Client run.

tl;dr
Try
chef-client -l debug

More info at: (search for log_level)
https://docs.chef.io/ctl_chef_client.html

Tuesday, August 5, 2014

Syntactical Conflict

Syntactical conflicts are never fun but it happens and we have to deal with it. I wanted to open firewall ports on servers, in this case, hosting Doom. To manage my server, I am want to use Chef. An issue I ran across was that my command, in Snippet 1, would work when run from PowerShell but not in Chef.

Snippet 1
netsh advfirewall firewall add rule dir=in name="Doom" program=%systemroot%\system32\svchost.exe service=doom action=allow protocol=TCP localport=666

It did not work when the command was run using Chef on the same Windows Server. Snippet 2 shows the code that did not work when run in Chef after copying directly into an execute block.

Snippet 2
# Firewall rule addition to enable a firewall port
execute "Doom TCP 666" do
  command "netsh advfirewall firewall add rule dir=in name="Doom" program=%systemroot%\system32\svchost.exe service=doom action=allow protocol=TCP localport=666"
end

The issue can be seen more clearly in the error, seen below in Figure 1.

Figure 1

As we can see, the value of "program" and "name" are distorted. We need to ensure that we are using literal " and literal \. The fix to this problem is simple if we add an additional \ in front of the characters that we want to take literally. The fix is seen in Snippet 3.

Snippet 3
# Firewall rule addition to enable a firewall port
execute "Doom TCP 666" do
  command "netsh advfirewall firewall add rule dir=in name=\"Doom\" program=\"%systemroot%\\system32\\svchost.exe\" service=doom action=allow protocol=TCP localport=666"
end

Our path will no longer be distorted and our name will be accepted. This can apply directly to the firewall port problem or more broadly in scenarios where Chef will be running PowerShell with the execute command.

Tuesday, July 22, 2014

Anti-Pattern Accident

Yesterday marked the first day that I fully realized that I am creating a Chef cookbook using an anti-pattern. I needed to use the community OpenSSH cookbook but it does install the version of OpenSSH to meet my requirements. The repositories that I am using did not have the 6.x version which was necessary for the requirements. The operating system and community cookbook would only try to install the 5.x version from the original repos. This was not the desired functionality as we need to upgrade versions.

This is when my anti-pattern failure happens! I decided that I need to modify the cookbook to use the upgrade action rather than install action. Our configuration of the ssh_config and sshd_configs are also very specific so those attributes needed changed as well. I went ahead and made these changes in my copy of the community cookbook. I now realize that this was an unsustainable and poor decision. I will be refactoring over the next few days to get the cookbooks separate and sustainable. Hopefully in the future I will continue to notice my mistakes. I will definitely have to keep an eye on this as I am learning Chef on my own without much guidance. 


Thanks to the following two blogs for helping me to realize my mistake!

My original finding (Great summary/bulleting):
http://dougireton.com/blog/2013/02/16/chef-cookbook-anti-patterns/

Linked from above (Great info):
http://devopsanywhere.blogspot.com/2012/11/how-to-write-reusable-chef-cookbooks.html

Monday, July 7, 2014

I'm back in action!

Long time, no type! That is my bad everyone, I have been very bad about keeping up with this blog. My life was kind of hectic for awhile with the transition from college student to IT professional. I am getting back into the swing of things and am becoming comfortable at my new position.

My role now is a Web Architect with Sogeti USA, as a contractor. I am working on automating server infrastructure through the use of Chef. I am also migrating web applications from their current location to cloud infrastructure.

The position is a blend of infrastructure and development which is a a perfect fit for me. I am looking forward to my role doing Chef work and hope that it continues. I will be posting more about Chef, the issues I've come across, and general things I've learned.