Year: 2016

Share your public keys easily with GitHub

Here’s a handy thing that I didn’t know about – you can easily share your public keys by adding them to your GitHub account and then accessing the URL of the form https://github.com/YOUR_USERNAME.keys . What you get is a plain text response with all your public keys, ready to be inserted into .ssh/authorized_keys file or anywhere else you want them.

Here’s an example of mine – https://github.com/mamchenkov.keys . Don’t forget to configure two factor authentication for your GitHub account for an extra layer of security. You probably don’t want any bugger who got your password inserting his own public keys into your account.

Top level domain nonsense and how it can break your stuff

Call me old school, but I really (I mean REALLY) don’t like the recent explosion of the top level domains. I understand that most good names are taken in .com, .org, and .net zones, but do we really need all those .blue, .parts, and .yoga TLDs?

Why am I whining about all this all of a sudden? I’ll tell you why. Because a new top level domain – .aws – is about to be introduced, and it already broke something for me in a non-obvious manner.

I manage a few Virtual Private Clouds on the Amazon AWS. Many of these use and rely on some hostname naming convention (yeah, I’m familiar with the pets vs. cattle idea). Imagine you have a few servers, which are separated into generic infrastructure and client segments, like so:

bastion.aws.example.com
firewall.aws.example.com
lb.aws.example.com
web.client1.example.com
db.client1.example.com
web.client2.example.com
db.client2.example.com
… and so on.

Working with such long FQDNs (fully qualified domain names) isn’t very convenient. So add “search example.com” to your /etc/resolve.conf file and now you can use short hostnames like firewall.aws and web.client1. And life is beautiful …

… until one day, when you see the following:

user@bastion.aws$> ssh firewall.aws
Permission denied (publickey).

And that’s when your heart misses a beat, the world freezes, and you go: “WTF?”. All kinds of thoughts are rushing through your head. Is it a typo? Am I in the right place? Did the server get compromised? How’s that for a little panic …

Trying a few things here and there, you manage to get into the server from somewhere else. You are very careful. You are looking around for any traces of the break-in, but you see nothing. You dig through the logs both on the server and off it. Still nothing. You can dive into all those logwatch and cron messages in your Trash, that you were automatically deleting, cause things were working fine for so long. There! You find that cron was complaining that backup script couldn’t get into this machine. Uh-oh. This was happening for a few days now. A black cloud of combined worry for the compromised machine and outdated backup kills the sunlight in your life. Dammit!

Take a break to calm down. Try to think clearly. Don’t panic. Stop assuming things, and start troubleshooting.

A few minutes later, you establish that the problem is not limited to that particular machine. All your .aws hosts share this headache. A few more minutes later, you learn that ‘ssh firewall.aws.example.com’ works fine, while ‘ssh firewall.aws’ still doesn’t.

That points toward the hostname resolution issue. With that, it takes only a few more moments to see the following:

user@bastion.aws$> host firewall.aws
firewall.aws has address 127.0.53.53
firewall.aws mail is handled by 10 your-dns-needs-immediate-attention.aws.

Say what? That’s not at all what I expected. And what is that that I need to fix with my DNS? Google search brings this beauty:

This is problably because the .dev and .local are now valid top level extensions.

Really? Who’s the genius behind that? I thought people chose those specifically to make them internal. So is there an .aws top level extension now too? You bet there is!

Solution? Well, as far as I am concerned, from this day onward, I don’t trust the brief hostnames anymore. It’s FQDN or nothing.

Ansible setup for Fedora project

Real life working examples are some of the most useful things when learning a new system. The more – the better. That’s why this git repository of the Ansible setup for the Fedora project is a pure gold mine. It is large. It is complex. It covers a whole lot of things. But most importantly, it is alive and well tested.

First attempt at Ansible

After all the reading about Ansible that I’ve done yesterday, I woke up today with a strong will to try it out. Running a few “hello world” examples wasn’t illustrative enough, so I decided to migrate my dotfiles repository from Puppet to Ansible. This would provide just enough complexity to try things out, without any danger of breaking things horribly.

I’m proud to say that it took me only about two-three hours of trying things out to complete this task. In the process, the following things were tried:

Ansible best practices
Playbooks (site.yml)
Roles (dotfiles, fonts, vim, git)
Tasks (file system operations, package installation, git repositories)
Tags (I’m using files, packages, network)
Loops (file globs, ad hoc items, pre-defined lists)
Filters (basename is super handy)
Inventories (mostly for variables, but played around with hosts too)
Variables (lists definitions for tasks, variables for templates)
Templates (.gitconfig with the user name, email, and GitHub username).

One of the things that I haven’t tried yet is using non-core modules (Ansible Galaxy, etc). I will, eventually. But for now I have to say that Ansible provides enough functionality out of the box to run the most common tasks.

When I was done, the resulting change set had (according to diffstat):

213 files changed,
2,177 lines inserted,
11,975 lines deleted.

The majority of these changes were, of course, the removal of Puppet modules from the repository, not the actual configurations.

My initial impressions are:

Ansible is indeed much easier and simpler to get started with. Maybe because I’ve already been through the configuration management initiation with Puppet.
Like any other system, it has its quirks, which will need time to get used to. For example, recursively coping a directory locally is not as easy as you might think.
YAML is not as bad as it looks, once you’ve been editing it for a couple of hours non-stop.

Overall, I’m pretty happy with how it goes. Next up – trying it out for provisioning some of my servers. And then, if all goes well, using it for project deployment as well.

Checking out Ansible. Sorry Puppet

It’s Thursday evening of a particularly difficult week at work. Tomorrow is a public holiday, effectively making this – a Friday. My brain is blank and exhausted, so I can’t do anything productive. And I’m too tired to go out. But I can still learn a thing or two.

First things first – cancel the external noise. I want something loud, but not too intensive, and with no words in it. So this 2 hour blues instrumental collection comes in handy. Start the playback, put the headphones on, and push the volume up.

Now. Here’s something I wanted to look into for quite some time – Ansible configuration manager.

Continue reading Checking out Ansible. Sorry Puppet