PoE, PoE+, and Passive PoE

If you’re befuddled by every Poe other than Edgar Allen, after this short blog post, you’ll be confused… nevermore.

I’ve been installing a lot of POE devices recently, and the different methods for providing power over Ethernet cables can be very confusing. There are a few standards in place, and then there’s a method that isn’t a standard, but is widely used.

802.3af or Active PoE:

This is the oldest standard for providing power over Ethernet cables. It allows a maximum of 15.4 watts of power to be transmitted, and the devices (switch and peripheral) negotiate the amount of power and the wires on which the power is transmitted. If a device says it is PoE-compliant, that compliance is usually referring to 802.3af.

802.3at or PoE+:

The main difference between PoE and PoE+ is the amount of power that can be transmitted. There is still negotiation to determine the amount of power and what wires it’s transmitted on, but PoE+ supports up to 25.5 watts of power. Often, access points with multiple radios or higher-powered antennas require more power than 802.3af can supply.

Passive PoE:

This provides power over the Ethernet lines, but it doesn’t negotiate the amount of power or the wires on which the power is sent. Many devices use Passive PoE (notably, the Ubiquiti line of network hardware often uses 24v Passive PoE) to provide power to remote devices. With Passive PoE, the proprietary nature of the power specifics means that it’s often wise to use only power injectors or switches specifically designed for the devices that require Passive PoE. The power is “always on”, so it’s possible to burn out devices if they’re not prepared for electrified Ethernet wires, or if the CAT5 cabling is wired incorrectly.

Figure 1. This AP requires a Passive PoE 24v supply. It can be confusing, because even though it says it’s PoE, it won’t power on using a standard 802.3af switch.

The best practice for using power over Ethernet is either to use equipment that adheres to the 802.3af/at standards or to use the power injectors or switches specifically designed for the hardware. Usually, the standard-based PoE devices are more expensive, but the ability to use any brand PoE switch and device often makes the extra expense worthwhile. That said, there’s nothing wrong with Passive PoE, as long as the correct power is given to the correct devices.

Finding the Joy in 2019

Nigel enjoyed 2019. Especially the fishy bits.
Nigel enjoyed 2019. Especially the fishy bits.

This won’t be a long, navel-gazing post about all the wisdom I’ve gathered over the past year. Rather, a quick list of things that stuck out to me. And honestly, it’ll probably largely be from the past couple months, because a year is a long time to remember. And I didn’t take notes. 🙂

  • Happiness is a funny thing. I realized this year that, for me at least, happiness isn’t the result of things done well. Rather, happiness tends to cause things to go well. If I focus first on being happy, content, and having fun — those things like work, family, and hobbies tend to be more successful. And how does one focus on being happy? Oddly enough, choosing to be happy.
  • Facebook isn’t a good source for news. But (un?)fortunately it’s a really good place to find out about people in your life. If you want to see who a person really is, look at what they post/share/like. Or don’t, because it’s often more heartbreaking than anything.
  • Proxmox is awesome. Sorry in advance to my non-nerdy friends, but Proxmox is a virtualization platform, and I’m sad to say I haven’t used it before this year. I’ve been so very foolish to wait. It’s incredible. Hopefully you’ll hear more about it from me in 2020, because holy cat biscuits am I a fan.
  • eBay is a great place to buy servers. If you can deal with last-generation hardware, buying use/reconditioned servers on eBay is so affordable, it feels criminal. Granted buying used equipment forces you to focus on redundancy and backups in case of failure — but shouldn’t you be focusing on those things anyway?!?!?
  • Losing weight is HARD. And it’s even harder for women than men. I lost over 50 pounds this year, and although I gained back 11-ish over the holidays, the past 6 months have been a big first step in a lifestyle change. I’m in my mid-40s now, and I need to eat far less, and exercise far more often than I did in decades past. I want to get really old someday, and keeping my body healthy and strong is an important part of that goal.
  • Point of view is critical. I’m a pretty sickly guy. From bad lungs, to bad kidneys, to heart concerns in my 20s — there’s a lot wrong with me. (Seriously, that’s just a tiny fraction of my issues, I don’t want to depress anyone with the entire list, especially myself!) I try daily to focus on how healthy I am in spite of all the things working against me. I’m not sickly, I’m impossible to kill!
  • Learning is awesome. Yeah, I know, I’m a trainer by profession so this sounds like a marketing tactic, but I mean for myself as much as anyone else. I absolutely love learning. This year alone I:
    • Built a hydroponic system in my basement
    • Learned this decade’s nuances with video and live-streaming
    • Installed lighting systems of multiple brands/kinds/styles all over my house and office
    • Learned a bit of a new programming language (python)
    • Read over a book a week
    • Left the country (this is a big deal for me, it’s a phobia)
    • Fixed a refrigerator
    • Installed a dishwasher
    • Bought/used/learned/installed/played_with more technology and gadgets than anyone has a right to
    • Finally pinned a tweet (sorry it took so long, Jake!)

I don’t know what 2020 has in store for me health-wise, work-wise, etc. — but I know that if I approach it purposely filled with joy first, it will be far better than if I try to create happiness by doing things. If I learned anything from 2019, it’s that joy is a choice. A decision. And it puts all the other things in place, regardless of what those things might be. Happy New Year, everyone. Let’s make it awesome together. 🙂

Grepping is Awesome. Just Don’t Glob it Up!

Greps and pipes and greps and pipes and greps and pipes…

This article covers some grep and regex basics.

There are generally two types of coffee drinkers. The first type buys a can of pre-ground beans and uses the included scoop to make their automatic drip coffee in the morning. The second type picks single-origin beans from various parts of the world, accepts only beans that have been roasted within the past week and grinds those beans with a conical burr grinder moments before brewing in any number of complicated methods. Text searching is a bit like that.

For most things on the command line, people think of *.* or *.txt and are happy to use file globbing to select the files they want. When it comes to grepping a log file, however, you need to get a little fancier. The confusing part is when the syntax of globbing and regex overlap. Thankfully, it’s not hard to figure out when to use which construct.

Globbing

The command shell uses globbing for filename completion. If you type something like ls *.txt, you’ll get a list of all the files that end in .txt in the current directory. If you do ls R*.txt, you’ll get all the files that start with capital R and have the .txt extension. The asterisk is a wild card that lets you quickly filter which files you mean.

You also can use a question mark in globbing if you want to specify a single character. So, typing ls read??.txt will list readme.txt, but not read.txt. That’s different from ls read*.txt, which will match both readme.txt and read.txt, because the asterisk means “zero or more characters” in the file glob.

Here’s the easy way to remember if you’re using globbing (which is very simple) vs. regular expressions: globbing is done to filenames by the shell, and regex is used for searching text. The only frustrating exception to this is that sometimes the shell is too smart and conveniently does globbing when you don’t want it to—for example:


grep file* README.TXT

In most cases, this will search the file README.TXT looking for the regular expression file*, which is what you normally want. But if there happens to be a file in the current folder that matches the file* glob (let’s say filename.txt), the shell will assume you meant to pass that to grep, and so grep actually will see:


grep filename.txt README.TXT

Gee, thank you so much Mr. Shell, but that’s not what I wanted to do. For that reason, I recommend always using quotation marks when using grep. 99% of the time you won’t get an accidental glob match, but that 1% can be infuriating. So when using grep, this is much safer:


grep "file*" README.TXT

Because even if there is a filename.txt, the shell won’t substitute it automatically.

So, globs are for filenames, and regex is for searching text. That’s the first thing to understand. The next thing is to realize that similar syntax means different things.

Glob and Regex Conflicts

I don’t want this article to become a super in-depth piece on regex; rather, I want you to understand simple regex, especially as it conflicts with blobbing. Table 1 shows a few of the most commonly confused symbols and what they mean in each case.

Table 1. Commonly Used Symbols

Special CharacterMeaning in GlobsMeaning in Regex
*zero or more characterszero or more of the character it follows
?single occurrence of any characterzero or one of the character it follows but not more than 1
.literal “.” characterany single character

To add insult to injury, you might be thinking about globs when you use grep, but just because you get the expected results doesn’t mean you got the results for the correct reason. Let me try to explain. Here is a text file called filename.doc:


The fast dog is fast.
The faster dogs are faster.
A sick dog should see a dogdoc.
This file is filename.doc

If you type:


grep "fast*" filename.doc

The first two lines will match. Whether you’re thinking globs or regex, that makes sense. But if you type:


grep "dogs*" filename.doc

The first three lines will match, but if you’re thinking in globs, that doesn’t make sense. Since grep uses regular expressions (regex) when searching files, the asterisk means “zero or more occurrences of the previous character”, so in the second example, it matches dog and dogs, because having zero “s” characters matches the regex.

And let’s say you typed this:


grep "*.doc" filename.doc

This will match the last two lines. The asterisk doesn’t actually do anything in this command, because it’s not following any character. The dot in regex means “any character”, so it will match the “.doc”, but it also will match “gdoc” in “dogdoc”, so both lines match.

The moral of the story is that grep never uses globbing. The only exception is when the shell does globbing before passing the command on to grep, which is why it’s always a good idea to use quotation marks around the regular expression you are trying to grep for.

Use fgrep to Avoid Regex

If you don’t want the power of regex, it can be very frustrating. This is especially true if you’re actually looking for some of the special characters in a bunch of text. You can use the fgrep command (or grep -F, which is the same thing) in order to skip any regex substitutions. Using fgrep, you’ll search for exactly what you type, even if they are special characters. Here is a text file called file.txt:


I really hate regex.
All those stupid $, {}, and \ stuff ticks me off.
Why can't text be text?

If you try to use regular grep like this:


grep "$," file.txt

you’ll get no results. That’s because the “$” is a special character (more on that in a bit). If you’d like to grep for special characters without escaping them, or knowing the regex code to get what you want, this will work fine:


grep -F "$," file.txt

And, grep will return the second line of the text file because it matches the literal characters. It’s possible to build a regex query to search for special characters, but it can become complicated quickly. Plus, fgrep is much, much faster on a large text file.

Some Simple, Useful Regex

Okay, now that you know when to use globbing and when to use regular expressions, let’s look at a bit of regex that can make grepping much more useful. I find myself using the caret and dollar sign symbols in regex fairly often. Caret means “at the beginning of the line”, and dollar sign means “at the end of the line”. I used to mix them up, so my silly method to remember is that a farmer has to plant carrots at the beginning of the season in order to sell them for dollars at the end of the season. It’s silly, but it works for me!

Here’s a sample text file named file.txt:


chickens eat corn
corn rarely eats chickens
people eat chickens and corn
chickens rarely eat people

If you were to type:


grep "chickens" file.txt

you will get all four lines returned, because “chickens” is in each line. But if you add some regex to the mix:


grep "^chickens" file.txt

you’ll get both the first and fourth line returned, because the word “chickens” is at the beginning of those lines. If you type:


grep "corn$" file.txt

you will see the first and third lines, because they both end with “corn”. However, if you type:


grep "^chickens.*corn$" file.txt

you will get only the first line, because it is the only one that begins with chickens and ends with corn. This example might look confusing, but there are three regular expressions that build the search. Let’s look at each of them.

First, ^chickens means the line must start with chickens.

Second, .* means zero or more of any character, because remember, the dot means any character, and the asterisk means zero or more of the previous character.

Third, corn$ means the line must end with corn.

When you’re building regular expressions, you just mush them all together like that in a long string. It can become confusing, but if you break down each piece, it makes sense. In order for the entire regular expression to match, all of the pieces must match. That’s why only the first line matches the example regex statement.

A handful of other common regex characters are useful when grepping text files. Remember just to mush them together to form the entire regular expression:

  • \ â€” the backslash negates the “special-ness” of special characters, which means you actually can search for them with regex. For example, \$ will search for the $ character, instead of looking for the end of a line.
  • \s â€” this construct means “whitespace”, which can be a space or spaces, tabs or newline characters. To find the word pickle surrounded by whitespace, you could search for \spickle\s, and that will find “pickle” but not “pickles”.
  • .* â€” this is really just a specific use of the asterisk, but it’s a very common combination, so I mention it here. It basically means “zero or more of any characters”, which is what was used in the corn/chicken example above.
  • | â€” this means “or” in regex. So hi|hello will match either “hi” or “hello”. It’s often used in parentheses to separate it from other parts of the regular expression. For example, (F|f)rankfurter will search for the word frankfurter, whether or not it’s capitalized.
  • [] â€” brackets are another way to specify “or” options, but they support ranges. So the regex [Ff]rankfurter is the same as the above example. Brackets support ranges though, so ^[A-Z] will match any line that starts with a capital letter. It also supports numbers, so [0-9]$ will match any line that ends in a digit.

Your Mission

You can do far more complicated things with regular expressions. These basic building blocks are usually enough to get the sort of text you need out of a log file. If you want to learn more, by all means, either do some googling on regex, or get a book explaining all the nitty-gritty goodness. If you want me to write more about it, drop a comment and let me know.

I really, really encourage you to practice using regex. The best way to learn is to do, so make a few text files and see if the regex statements you create give you the results you expect. Thankfully, grep highlights the “match” it finds in the line it returns. That means if you’re getting more results than you expect, you’ll see why the regex matched more than you expected, because grep will show you.

The most important thing to remember is that grep doesn’t do globbing—that wild-card stuff is for filenames on the shell only. Even if globbing with grep seems to work, it’s probably just coincidence (look back at the dog/dogs example here if you don’t know what I’m talking about). Have fun grepping!

The Powers Family Christmas Eve Scavenger Hunt

Every year, since our (now adult) girls were tiny, Donna and I have created a scavenger hunt for our kids on Christmas Eve. They follow clues, solve puzzles, and at the end, there’s a group gift/prize for them to enjoy together. It’s not our only family tradition, but it’s by far the biggest and most consistent one we have. Since we’ve started livestreaming the shenanigans every December 24th, we’ve gotten quite a few inquiries about how we do it.

This is the answer, in the form of recommendations if you want to do your own version.

Make it easy to set up, or it won’t be a tradition, it’ll be a single fun memory.

Donna and I don’t usually prepare weeks or even days in advance. Some years, we’ve created clues on the fly, while the girls are doing the hunt. We want it to be a tradition, not a burden. We used to have a tradition of making a Christmas Star together every year. But it turns out that can be difficult to do, and the tradition fizzled. We’ve NEVER missed a year with our scavenger hunt, because we never let it become a burden. It’s truly not about how clever your clues are, or how many people are involved. It’s about doing silly things together, and even the lamest years have been a ton of fun.

Remember WHY you’re doing it.

Our goal has always been for our girls to have fun with each other. We’re not trying to stump them. There aren’t teams competing. They aren’t competing against each other. They’re just having fun working together. The final clue/solution is always something we can do together as a family afterward. Some years it’s a video game. Some years it’s a board game. Some years it’s a movie. It’s impossible to “lose” at the scavenger hunt, and if a clue is too challenging, we’ll totally help and give more clues, because it’s not about challenging the girls. It’s about the girls having fun TOGETHER.

Include everyone.

This isn’t something we have to remind our girls of anymore. They know it’s about everyone having fun, so they go out of their way to include each other and anyone else that might be with them that year. But at the beginning, or especially if your group is varied in age — make a point to include everyone. Something too hard for little Johnny? Let him hold the video camera while Suzy climbs the fence, etc, etc.

Consider your participants’ ages.

Our girls are fairly close in age. When they were young, the scavenger hunt was an indoor event. When they got older, they’d have to go into the yard or on the Internet. (See a clue from 2010: https://youtu.be/KfCDJv7ZXds ) Some years there are friend and/or relatives that go with the girls, and we make sure to consider their ages and abilities while designing the clues.

Now? The girls are all adults, and clues will take them around town and even to other towns. They’ll drive a half hour one way to get a picture with a street sign. And they’ll laugh together the WHOLE time. It’s seriously magical, and allowing friends, etc, join in has never been a problem. We play the scavenger hunt fast and loose, and that means it’s very flexible and age inclusive.

Consider video streaming publicly or privately.

Now that video streaming technology is possible with mobile devices, it has made the entire experience more fun and inclusive. Perhaps you’ve seen the livestream. It’s silly, it’s fun, and holding the phone/camera is something someone can do. If you don’t want to livestream, consider facetime.

How we actually do it now:

We take full advantage of technology. The girls have a phone livestreaming the whole time, for our enjoyment at home (Donna and I stay home). The actual clue/solution goes something like this:

  1. We text them a clue. “I’m downtown, but my phone died, and I’m not wearing a watch. How will I know what time it is?!??!”
  2. They figure out what we’re hinting at, and pile into a car together and drive (safely!) downtown. They get to the clock on main street, and take a photo of themselves in front of the clock.
  3. They text the photo to our family group text, and if they’re correct, they get sent the next clue.
  4. If they happen to go to the waterfront and get a photo in front of THAT clock, we’ll respond with something like, “when I’m downtown, I can’t see that clock…” — and they’ll figure out what we actually meant, and drive to the clock downtown and try again.
  5. Or, we’ll decide their solution was better than what we meant anyway, and pretend we meant the clock by the waterfront after all, and send them the next clue. 🙂

Sometimes, we’ll think ahead enough to have some jigsaw puzzles, which we put into an envelope and send with them. In which case, one of the clues they’ll receive via text is, “Open Envelope #2” — then they’ll follow the instructions inside the envelope.

Some of the clues involve them doing things like, “Open envelope #3, and use the $15 inside to buy hot cocoa from the bookstore, and get a stranger to take your photo” — then they send the photo to us to get the next clue.

We usually make them do some (slightly) embarrassing things, like going into a store and having one (or more) of them sing a Christmas Carol out loud while recording. They send the video to us, and we send the next clue/challenge.

Since it’s Christmas Eve, there’s usually a “build a snowman” challenge, which they need to accomplish and then take a photo and send it to us.

We’ll call a family/friend and make sure they’re home, then have a clue that has them go to XXX’s house and sing them “we wish you a Merry Christmas” while recording it, and we have the person give them the next clue (which we tell them when we call them, sometimes in advance, sometimes just before sending the clue, because we don’t prepare well, LOL)

End with some group fun.

Every “Just Dance” video game we own was the result of a scavenger hunt. We’ve had the last clue lead to a bowling alley (I think… maybe not, perhaps that will be this year’s prize), we’ve ended with video games, DVDs, etc, etc.

My biggest advice is to keep it simple. My girls rarely remember the clues or even the prizes at the end. They remember the fun they had doing silly, simple things together. They remember singing together in the car at the top of their lungs between clues. They remember anticipating the scavenger hunt. They tell their friends how awesome the tradition is, even if when they explain it, it doesn’t sound amazing. It’s far more about doing silly things together than the silly things themselves. 🙂

Good luck, and I hope your version is as much fun for your family as ours is for us!!!

Ansible Part 4: Putting it All Together

Roles are the most complicated and yet simplest aspect of Ansible to learn.

I’ve mentioned before that Ansible’s ad-hoc mode often is overlooked as just a way to learn how to use Ansible. I couldn’t disagree with that mentality any more fervently than I already do. Ad-hoc mode is actually what I tend to use most often on a day-to-day basis. That said, using playbooks and roles are very powerful ways to utilize Ansible’s abilities. In fact, when most people think of Ansible, they tend to think of the roles feature, because it’s the way most Ansible code is shared. So first, it’s important to understand the relationship between ad-hoc mode, playbooks and roles.

Ad-hoc Mode

This is a bit of a review, but it’s easy to forget once you start creating playbooks. Ad-hoc mode is simply a one-liner that uses an Ansible module to accomplish a given task on a set of computers. Something like:


ansible cadlab -b -m yum -a "name=vim state=latest"

will install vim on every computer in the cadlab group. The -b signals to elevate privilege (“become” root), the -m means to use the yum module, and the -a says what actions to take. In this case, it’s installing the latest version of vim.

Usually when I use ad-hoc mode to install packages, I’ll follow up with something like this:


ansible cadlab -b -m service -a "name=httpd state=started
 ↪enabled=yes"

That one-liner will make sure that the httpd service is running and set to start on boot automatically (the latter is what “enabled” means). Like I said at the beginning, I most often use Ansible’s ad-hoc mode on a day-to-day basis. When a new rollout or upgrade needs to happen though, that’s when it makes sense to create a playbook, which is a text file that contains a bunch of Ansible commands.

Playbook Mode

I described playbooks in my last article. They are YAML- (Yet Another Markup Language) formatted text files that contain a list of things for Ansible to accomplish. For example, to install Apache on a lab full of computers, you’d create a file something like this:


---

- hosts: cadlab
  tasks:
  - name: install apache2 on CentOS
    yum: name=httpd state=latest
    notify: start httpd
    ignore_errors: yes

  - name: install apache2 on Ubuntu
    apt: update_cache=yes name=apache2 state=latest
    notify: start apache2
    ignore_errors: yes

  handlers:
  - name: start httpd
    service: name=httpd enable=yes state=started

  - name: start apache2
    service: name=apache2 enable=yes state=started

Mind you, this isn’t the most elegant playbook. It contains a single play that tries to install httpd with yum and apache2 with apt. If the lab is a mix of CentOS and Ubuntu machines, one or the other of the installation methods will fail. That’s why the ignore_errors command is in each task. Otherwise, Ansible would quit when it encountered an error. Again, this method works, but it’s not pretty. It would be much better to create conditional statements that would allow for a graceful exit on incompatible platforms. In fact, playbooks that are more complex and do more things tend to evolve into a “role” in Ansible.

Roles

Roles aren’t really a mode of operation. Actually, roles are an integral part of playbooks. Just like a playbook can have tasks, variables and handlers, they can also have roles. Quite simply, roles are just a way to organize the various components referenced in playbooks. It starts with a folder layout:


roles/
  webserver/
    tasks/
      main.yml
    handlers/
      main.yml
    vars/
      main.yml
    templates/
      index.html.j2
      httpd.conf.j2
    files/
      ntp.conf

Ansible looks for a roles folder in the current directory, but also in a system-wide location like /etc/ansible/roles, so you can store your roles to keep them organized and out of your home folder. The advantage of using roles is that your playbooks can look as simple as this:


---

- hosts: cadlab
  roles:
    - webserver

And then the “webserver” role will be applied to the group “cadlab” without needing to type any more information inside your playbook. When a role is specified, Ansible looks for a folder matching the name “webserver” inside your roles folder (in the current directory or the system-wide directory). It then will execute the tasks inside webserver/tasks/main.yml. Any handlers mentioned in that playbook will be searched for automatically in webserver/handlers/main.yml. Also, any time files are referenced by a template module or file/copy module, the path doesn’t need to be specified. Ansible automatically will look inside webserver/files/ or /webserver/templates/ for the files.

Basically, using roles will save you lots of path declarations and include statements. That might seem like a simple thing, but the organization creates a standard that not only makes it easy to figure out what a role does, but also makes it easy to share your code with others. If you always know any files must be stored in roles/rolename/files/, it means you can share a “role” with others and they’ll know exactly what to do with it—namely, just plop it in their own roles folder and start using it.

Sharing Roles: Ansible Galaxy

One of the best aspects of current DevOps tools like Chef, Puppet and Ansible is that there is a community of people willing to share their hard work. On a small scale, roles are a great way to share with your coworkers, especially if you have roles that are customized specifically for your environment. Since many of environments are similar, roles can be shared with an even wider audience—and that’s where Ansible Galaxy comes into play.

I’ll be honest, part of the draw for me with Ansible is the sci-fi theme in the naming convention. I know I’m a bit silly in that regard, but just naming something Ansible or Ansible Galaxy gets my attention. This might be one of those “built by nerds, for nerds” sort of things. I’m completely okay with that. If you head over to the Galaxy site, you’ll find the online repository for shared roles—and there are a ton.

For simply downloading and using other people’s roles, you don’t need any sort of account on Ansible Galaxy. You can search on the website by going to Galaxy and clicking “Browse Roles” on the left side of the page (Figure 1). There are more than 13,000 roles currently uploaded to Ansible Galaxy, so I highly recommend taking advantage of the search feature! In Figure 2, you’ll see I’ve searched for “apache” and sorted by “downloads” in order to find the most popular roles.

Figure 1. Click that link to browse and search for roles.

Figure 2. Jeff Geerling’s roles are always worth checking out.

Many of the standard roles you’ll find that are very popular are written by Jeff Geerling, whose user name is geerlingguy. He’s an Ansible developer who has written at least one Ansible book that I’ve read and possibly others. He shares his roles, and I encourage you to check them out—not only for using them, but also for seeing how he codes around issues like conditionally choosing the correct module for a given distribution and things like that. You can click on the role name and see all the code involved. You might notice that if you want to examine the code, you need to click on the GitHub link. That’s one of the genius moves of Ansible Galaxy—all roles are stored on a user’s GitHub page as opposed to an Ansible Galaxy server. Since most developers keep their code on GitHub, they don’t need to remember to upload to Ansible Galaxy as well.

Incidentally, if you ever desire to share your own Ansible roles, you’ll need to use a GitHub user name to upload them, because again, roles are all stored on GitHub. But that’s getting ahead of things; first you need to learn how to use roles in your environment.

Using ansible-galaxy to Install Roles

It’s certainly possible to download an entire repository and then unzip the contents into your roles folder. Since they’re just text files and structured folders, there’s not really anything wrong with doing it that way. It’s just far less convenient than using the tools built in to Ansible.

There is a search mechanism on the Ansible command line for searching the Ansible Galaxy site, but in order to find a role I want to use, I generally go to the website and find it, then use the command-line tools to download and install it. Here’s an example of Jeff Geerling’s “apache” role. In order to use Ansible to download a role, you need to do this:


sudo ansible-galaxy install geerlingguy.apache

Notice two things. First, you need to execute this command with root privilege. That’s because the ansible-galaxy command will install roles in your system-wide roles folder, which isn’t writable (by default) by your regular user account. Second, take note of the format of roles named on Ansible Galaxy. The format is username.rolename, so in this case, geerlingguy.apache, which is also how you reference the role inside your playbooks.

If you want to see roles listed with the correct format, you can use ansible-galaxy‘s search command, but like I said, I find it less than useful because it doesn’t sort by popularity. In fact, I can’t figure out what it sorts by at all. The only time I use the command-line search feature is if I also use grep to narrow down roles by a single person. Anyway, Figure 3 shows what the results of ansible-galaxy search look like. Notice the username.rolename format.

Figure 3. I love the command line, but these search results are frustrating.

Once you install a role, it is immediately available for you to use in your own playbooks, because it’s installed in the system-wide roles folder. In my case, that’s /etc/ansible/roles (Figure 4). So now, if I create a playbook like this:


---
- hosts: cadlab
  roles:
    - geerlingguy.apache

Apache will be installed on all my cadlab computers, regardless of what distribution they’re using. If you want to see how the role (which is just a bunch of tasks, handlers and so forth) works, just pick through the folder structure inside /etc/ansible/roles/geerlingguy.apache/. It’s all right there for you to use or modify.

Figure 4. Easy Peasy, Lemon Squeezy

Creating Your Own Roles

There’s really no magic here, since you easily can create a roles folder and then create your own roles manually inside it, but ansible-galaxy does give you a shortcut by creating a skeleton role for you. Make sure you have a roles folder, then just type:


ansible-galaxy init roles/rolename

and you’ll end up with a nicely created folder structure for your new role. It doesn’t do anything magical, but as someone who has misspelled “Templates” before, I can tell you it will save you a lot of frustration if you have clumsy fingers like me.

Sharing Your Roles

If you get to the point where you want to share you roles on Ansible Galaxy, it’s fairly easy to do. Make sure you have your role on GitHub (using git is beyond the scope of this article, but using git and GitHub is a great way to keep track of your code anyway). Once you have your roles on GitHub, you can use ansible-galaxy to “import” them into the publicly searchable Ansible Galaxy site. You first need to authenticate:


ansible-galaxy login

Before you try to log in with the command-line tool, be sure you’ve visited the Ansible Galaxy website and logged in with your GitHub account. You can see in Figure 5 that at first I was unable to log in. Then I logged in on the website, and after that, I was able to log in with the command-line tool successfully.

Figure 5. It drove me nuts trying to figure out why I couldn’t authenticate.

Once you’re logged in, you can add your role by typing:


ansible-galaxy import githubusername githubreponame

The process takes a while, so you can add the -no-wait option if you want, and the role will be imported in the background. I really don’t recommend doing this until you have created roles worth sharing. Keep in mind, there are more than 13,000 roles on Ansible Galaxy, so there are many “re-inventions of the wheel” happening.

From Here?

Well, it’s taken me four articles, but I think if you’ve been following along, you should be to the point where you can take it from here. Playbooks and roles are usually where people focus their attention in Ansible, but I also encourage you to take advantage of ad-hoc mode for day-to-day maintenance tasks. Ansible in some ways is just another DevOps configuration management tool, but for me, it feels the most like the traditional problem-solving solution that I used Bash scripts to accomplish for decades. Perhaps I just like Ansible because it thinks the same way I do. Regardless of your motivation, I encourage you to learn Ansible enough so you can determine whether it fits into your workflow as well as it fits into mine.

If you’d like more direct training on Ansible (and other stuff) from yours truly, visit me at my DayJob as a trainer for CBT Nuggets. You can get a full week free if you head over to https://cbt.gg/shawnp0wers and sign up for a trial!

The 4 Part Series on Ansible includes:
Part 1 – DevOps for the Non-Dev
Part 2 – Making Things Happen
Part 3 – Playbooks
Part 4 – Putting it All Together