When it comes to tcpdump most admins fall into two categories; they either know tcpdump and all of its flags like the back of their hand, or they kind of know it but need to use a reference for anything outside of the basic usage. The reason for this is because tcpdump is a pretty advanced command and it is pretty easy to get into the depths of how networking works when using it....
Lately I've been working on a lot of automation and monitoring projects, a big part of these projects are taking existing scripts and modifying them to be useful for automation and monitoring tools. One thing I have noticed is sometimes scripts use exit codes and sometimes they don't. It seems like exit codes are easy for poeple to forget, but they are an incredibly important part of any script. Especially if that script is used for the command line....
When I was first got started with administrating Linux and Unix servers I was working in an environment where there were tons of adhoc scripts that other admins wrote. From time to time I would find myself troubleshooting why one of those scripts suddenly stopped working. Sometimes the scripts would be well written and easy to understand, other times they were clunky and confusing. While troubleshooting the poorly written scripts was always a hassle at the time, it taught me an important lesson....
Before the advent of a distributed domain name system; networked computers used local files to map hostnames to IP addresses. On Unix systems this file was named /etc/hosts or “the hosts file”. In those days, networks were small and managing a file with a handful of hosts was easy. However as the networks grew so did the methods of mapping hostnames and IP addresses. In modern days with the internet totaling at somewhere around 246 million domain names (as of 2012) the hosts file has been replaced with a more scalable distributed DNS service....
A few weeks back I wrote an article Getting started with SaltStack; that article covered Configuration and Package Automation with Saltstack. In Today's article I am going to cover SaltStack's Remote Execution abilities, a feature that I feel Saltstack has implemented better than other automation tools. Running a command in a State If you remember from the previous article SaltStack's states are permanent configurations. Adding a command in a Salt state is used when you want to have a command that is run after provisioning a server, run every time Salt manages the state of the system or run when certain conditions are true....