I have a 48TB NAS in my basement. Granted, thanks to RAID6 I only (only!) have 36TB of usable space, but still, I assumed that would last me forever. Thanks to ripping DVDs and Blurays, I was so very, very wrong. Rather than spend a few thousand dollars on a new NAS, however, I decided to host my files in the cloud. The storage is unlimited for $12/month, and after 6 months or so, I can tell you it’s a viable alternative to local storage. Plus, it mounts exactly like a local NAS!
The Service
There are plenty of cloud-based storage solutions available, but they are all either very limited in storage space, or very expensive per GB. There is one solution, however, that provides unlimited storage for a set monthly price. Google Drive.
Officially, in order to get unlimited storage, you must get a Business Gsuite with 5 users. Each user is $12/month, and so you’d have to pay $60/month to get unlimited storage. Honestly, $60 a month for that much space is still insanely affordable — but if you open a Business Gsuite account with a single user (so only $12/mo), you still get unlimited storage. It might seem like an error Google would quickly fix, but it’s been that way for years. I’m currently using more than 40TB of space on my Google Drive, and only have a single user on my Gsuite for Business.
The Problem
Google Drive is nice, but let’s be honest, no one wants to use their web interface as bulk storage. It’s clumsy, slow, and as much as I love Google, the organization is confusing at best. Google does provide “Google Drive Stream”, but due to local caching, you still need local storage or you get “not enough space” errors.
Thankfully, Rclone makes direct access to Google Drive seamless. It allows you to create access via keypair (no annoying logging in all the time), and even lets you mount your remote share on your local filesystem. And in true Steve Jobs “one more thing” fashion, it also allows you to encrypt files and directories in real time, so your privacy is protected even if your data is stored on someone else’s hard drive. It’s seriously amazing. And Rclone? Open Source and totally free!
The Process
Rclone is in most Linux distributions, and even has Windows and OSX versions available that all work similarly. In this video, I show you how to quickly set up a share and mount it on the local filesystem. If it seems too good to be true, yeah, I get that. But I’ve been using it for months and I’ve been more than impressed. It’s been reliable, and robust enough to support a handful of users reading and writing at the same time.
You can do a bit of extra work to create your own application API, which will make the performance more robust. It doesn’t cost any extra money, but it’s admittedly a bit of confusing clicking.
The Training?
You probably know I create training for a living. I have more in-depth training on rclone over at CBT Nuggets. If you’re already a subscriber, you can go to https://snar.co/cbt-rclone to get to the skill directly.
If you’re not yet a subscriber at CBT Nuggets, you can see my Everything Linux course overview, which includes my rclone skill and many others. Feel free to sign up for a free trial if you want to view my training. https://snar.co/cbt-everythinglinux
(This isn’t a creepy bait and switch — the free video above really does walk you through the process. There’s just more capability if you’re interested in diving in deeper, and want to check out my professional DayJob training!)
[NOTE: This is a piece I wrote for Linux Journal a few years back. It’s still very relevant, and still important information for anyone dabbling in crypto. This seems like a good time of year to repost it.]
One for you, one for me, and 0.15366BTC for Uncle Sam.
When people ask me about bitcoin, it’s usually because someone told them about my days as an early miner. I had thousands of bitcoin, and I sold them for around a dollar each. At the time, it was awesome, but looking back—well you can do the math. I’ve been mining and trading with cryptocurrency ever since it was invented, but it’s only over the past few years that I’ve been concerned about taxes.
In the beginning, no one knew how to handle the tax implications of bitcoin. In fact, that was one of the favorite aspects of the idea for most folks. It wasn’t “money”, so it couldn’t be taxed. We could start an entire societal revolution without government oversight! Those times have changed, and now the government (at least here in the US) very much does expect to get taxes on cryptocurrency gains. And you know what? It’s very, very complicated, and few tax professionals know how to handle it.
What Is Taxable?
Cryptocurrencies (bitcoin, litecoin, ethereum and any of the 10,000 other altcoins) are taxed based on the “gains” you make with them. (Often in this article I mention bitcoin specifically, but the rules are the same for all cryptocurrency.) Gains are considered income, and income is taxed. What sorts of things are considered gains? Tons. Here are a few examples:
Mining.
Selling bitcoin for cash.
Trading one crypto coin for another on an exchange.
Buying something directly with bitcoin.
The frustrating part about taxes and cryptocurrency is that every transaction must be calculated. See, with cash transactions, a dollar is always worth a dollar (according to the government, let’s not get into a discussion about fiat currency). But with cryptocurrency, at any given moment, the coin is worth a certain amount of dollars. Since we’re taxed on dollars, that variance must be tracked so we are sure to report how much “money” we had to spend.
It gets even more complicated, because we’re taxed on the same bitcoin over and over. It’s not “double dipping”, because the taxes are only on the gains and losses that occurred between transactions. It’s not unfair, but it’s insanely complex. Let’s look at the life of a bitcoin from the moment it’s mined. For simplicity’s sake, let’s say it took exactly one day to mine one bitcoin:
1) After 24 hours of mining, I receive 1BTC. The market price for bitcoin that day was $1,000 per BTC. It took me $100 worth of electricity that day to mine (yes, I need to track the electrical usage if I want to deduct it as a loss).
Taxable income for day 1: $900.
2) The next day, I trade the bitcoin for ethereum on an exchange. The cost of bitcoin on this day is $1,500. The cost of ethereum on this day is $150. Since the value of my 1 bitcoin has increased since I mined it, when I make the trade on the exchange, I have to claim the increase in price as income. I now own 10 ethereum, but because of the bitcoin value increase, I now have more income. There are no deductions for electricity, because I already had the bitcoin; I’m just paying the capital gains on the price increase.
Taxable income for day 2: $500.
3) The next day, the price of ethereum skyrockets to $300, and the price of bitcoin plummets to $1,000. I decide to trade my 10 ethereum for 3BTC. When I got my ethereum, they were worth $1,500, but when I just traded them for BTC, they were worth $3,000. So I made $1,500 worth of profit.
Taxable income for day 3: $1,500.
4) Finally, on the 4th day, even though the price is only $1,200, I decide to sell my bitcoin for cash. I have 3BTC, so I get $3,600 in cash. Looking back, when I got those 3BTC, they were worth $1,000 each, so that means I’ve made another $600 profit.
Taxable income for day 4: $600.
It might seem unfair to be taxed over and over on the same initial investment, but if you break down what’s happening, it’s clear we’re only getting taxed on price increases. If the price drops and then we sell, our taxable income is negative for that, and it’s a deduction. If you have to pay a lot in taxes on bitcoin, it means you’ve made a lot of money with bitcoin!
Exceptions?
There are a few exceptions to the rules—well, they’re not really exceptions, but more clarifications. Since we’re taxed only on gains, it’s important to think through the life of your bitcoin. For example:
Employer paying in bitcoin: I work for a company that will pay me in bitcoin if I desire. Rather than a check going into my bank account, every two weeks a bitcoin deposit goes into my wallet. I need to track the initial cost of the bitcoin as I receive it, but usually employers will send you the “after taxes” amount. That means the bitcoin you receive already has been taxed. You still need to track what it’s worth on the day you receive it in order to determine gain/loss when you eventually spend it, but the initial total has most likely already been taxed. (Check with your employer to be sure though.)
Moving bitcoin from one wallet to another: this is actually a tougher question and is something worth talking about with your tax professional. Let’s say you move your bitcoin from a BitPay wallet to your fancy new Trezor hardware wallet. Do you need to count the gains/losses since the time it was initially put into your BitPay wallet? Regardless of what you and your tax professional decide, you’re not going to “lose” either way. If you decide to report the gain/loss, your cost basis for that bitcoin changes to the current date and price. If you don’t count a gain/loss, you stick to the initial cost basis from the deposit into the BitPay wallet.
The moral of the story here is to find a tax professional comfortable with cryptocurrency.
Accounting Complications
If you’re a finance person, terms like FIFO and LIFO make perfect sense to you. (FIFO = First In First Out, and LIFO = Last In First Out.) Although it’s certainly easy to understand, it wasn’t something I’d considered before the world of bitcoin. Here’s an example of how they differ:
Day 1: buy 1BTC for $100.
Day 2: buy 1BTC for $500.
Day 3: buy 1BTC for $1,000.
Day 4: buy 1BTC for $10,000.
Day 5: sell 1BTC for $12,000.
If I use FIFO to determine my gains and losses, when I sell the 1BTC on day 5, I have to claim a capital gain of $11,900. That’s considered taxable income. However, if I use LIFO to determine the gains and losses, when I sell the 1BTC on day 5, I have to claim only $2,000 worth of capital gains. The question is basically “which BTC am I selling?”
There are other accounting methods too, but FIFO and LIFO are the most common, and they should be okay to use with the IRS. Please note, however, that you can’t mix and match FIFO/LIFO. You need to pick one and stick with it. In fact, if you change the method from year to year, you need to change the method officially with the IRS, which is another task for your tax professional.
The Long and Short of It
Another complication when it comes to calculating taxes doesn’t have to do with gains or losses, but rather the types of gains and losses. Specifically, if you have an asset (such as bitcoin) for longer than a year before you sell it, it’s considered a long-term gain. That income is taxed at a lower rate than if you sell it within the first year of ownership. With bitcoin, it can be complicated if you move the currency from wallet to wallet. But if you can show you’ve had the bitcoin for more than a year, it’s very much worth the effort, because the long-term gain tax is significantly lower.
This was a big factor in my decision on whether to cash in ethereum or bitcoin for a large purchase I made this year. I had the bitcoin in a wallet, but it didn’t “age” as bitcoin for a full year. The ethereum had just been sitting in my Coinbase account for 13 months. I ended up saving significant money by selling the ethereum instead of a comparable amount of bitcoin, even though the capital gain amount might have been similar. The difference in long-term and short-term tax rates are significant enough that it’s worth waiting to sell if you can.
Overwhelmed?
If you’ve made only a couple transactions during the past year, it almost can be fun to figure out your gains/losses. If you’re like me, however, and you try to purchase things with bitcoin at every possible opportunity, it can become overwhelming fast. The first thing I want to stress is that it’s important to talk to someone who is familiar with cryptocurrency and taxes. This article wasn’t intended to prepare you for handling the tax forms yourself, but rather to show why you might need professional help!
Unfortunately, if you live in a remote rural area like I do, finding a tax professional who is familiar with bitcoin can be tough—or potentially impossible. The good news is that the IRS is handling cryptocurrency like any other capital gain/loss, so with the proper help, any good tax person should be able to get through it. FIFO, LIFO, cost basis and terms like those aren’t specific to bitcoin. The parts that are specific to bitcoin can be complicated, but there is an incredible resource online that will help.
If you head over to BitcoinTaxes (Figure 1), you’ll find an incredible website designed for bitcoin and crypto enthusiasts. I think there is a free offering for folks with just a handful of transactions, but for $29, I was able to use the site to track every single cryptocurrency transaction I made throughout the year. BitcoinTaxes has some incredible features:
Automatically calculates rates based on historical market prices.
Tracks gains/losses including long-term/short-term ramifications.
Handles purchases made with bitcoin individually and determines gains/losses per transaction (Figure 2).
Supports multiple accounting methods (FIFO/LIFO).
Integrates with online exchanges/wallets to pull data.
Creates tax forms.
The last bullet point is really awesome. The intricacies of bitcoin and taxes are complicated, but the BitcoinTaxes site can fill out the forms for you. Once you’re entered all your information, you can print the tax forms so you can deliver them to your tax professional. The process for determining what goes on the forms might be unfamiliar to many tax preparers, but the forms you get from BitcoinTaxes are standard IRS tax forms, which the tax pro will fully understand.
Figure 1. The BitcoinTaxes site makes calculating tax burdens far less burdensome.
Figure 2. If you do the math, you can see the price of bitcoin was drastically different for each transaction.
Do you need to pay $29 in order to calculate all your cryptocurrency tax information properly? Certainly not. But for me, the site saved me so many hours of labor that it was well worth it. Plus, while I’m a pretty smart guy, the BitcoinTaxes site was designed with the sole purpose of calculating tax information. It’s nice to have that expertise on hand.
My parting advice is please take taxes seriously—especially this year. The IRS has been working hard to get information from companies like Coinbase regarding taxpayer’s gains/losses. In fact, Coinbase was required to give the IRS financial records on 14,355 of its users. Granted, those accounts are only people who have more than $20,000 worth of transactions, but it’s just the first step. Reporting things properly now will make life far less stressful down the road. And remember, if you have a ton of taxes to pay for your cryptocurrency, that means you made even more money in profit. It doesn’t make paying the IRS any more fun, but it helps make the sore spot in your wallet hurt a little less.
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.
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 Character
Meaning in Globs
Meaning in Regex
*
zero or more characters
zero or more of the character it follows
?
single occurrence of any character
zero or one of the character it follows but not more than 1
.
literal “.” character
any 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!
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:
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:
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:
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!
