I am publishing four Terraform modules today. This code has lived into a private repository of mine for two years and I decided that it was time to dig it out, put it in dedicated, public repositories and release it. Two of them were my first experiments in making Terraform modules and probably too simple for general use. The other two are related to CFEngine: one helps making CFEngine test clients, the other making CFEngine servers.
As always, this code is released with a GPL license in the hope that it will be useful to more people than just myself.
Commands like the AWS CLI may return a list of values all in one line, where each item in the list is separated by the nearby items with spaces. Using a plain read command doesn’t really work: read will read all the values in one go into the variable. You need to change the delimiter that read uses to split the input. No need to pipe the output through Perl or other tools, read got you covered with the -d option.
In this example I get the list of the ARNs of all target groups in an AWS account, and then iterate over those ARNs to list all the instances in each target group. The ouput will also be saved into a file through the tee command:
aws elbv2 describe-target-groups \
--query 'TargetGroups.TargetGroupArn' \
--output text | \
while read -d ' ' ARN ; do \
echo -n "$ARN: " ; \
aws elbv2 describe-target-health \
--target-group-arn "$ARN" \
--query 'TargetHealthDescriptions.Target.Id' \
--output text ; sleep 1 ; \
done | \
The ouput of this one liner will be in the format:
ARN: instance_ID [instance_ID...]
Things to notice:
the AWS CLI’s describe-target-groups command will list all target groups’ ARNs thanks to the --query option and list as many as possible on single lines, according to the shell’s output buffer capacity; the ouput is piped through a while loop;
the while loop uses read -d ' ' to split each line at spaces and save each item in the $ARN variable, one per cycle;
the echo command prints the value of $ARN followed by a colon, a space, but will not output a newline sequence due to the -n option;
the AWS CLI’s describe-target-health command will list all target IDs thanks to the --query option and print them out in a single line; it will also provide a newline sequence, so that the next loop will start on a new line;
the sleep 1 command slows down the loop, so that we don’t hammer the API to the point that they will rate limit us;
finally, the tee command will duplicate the output of the while loop to both the standard output and the file tg-instances.txt.
In our team at RiksTV, the company I joined in March 2020, we use Python. I had never used Python before and I’m working as hard as I can to fill the gap.
During the Christmas break I assigned myself a small coding challenge, both to test what I have learned so far and to avoid that new knowledge to be washed away. I decided to share that code, and will continue sharing as I keep learning and whenever I make something that could be useful to more people than just myself. Head to github if you are interested.
A few weeks ago I found myself in need of a a place where I could share public encryption keys with others for a side project of mine. As the adjective public implies, there is nothing secret about public keys: they can be shared in the open safely, so that was not a concern. The problem was to find a convenient way to do that. More precisely, I needed a place where I could share certain public keys with everyone, and where anyone could put their public keys to share them with me, and with me only.
In the end, I turned to AWS S3 as it is a natural place to look at when it comes to file storage and sharing. But it took a lot of trial and error before I was actually able to find an appropriate configuration for the bucket. I also put some automation with terraform into the mix, both because I prefer to automate things that I may have to do several times, and because it turned out that I’ll have to bring this inbox of mine up and down at need. The outcome is a terraform module that I have just published on github.
TL;DR: I put together a Perl script that does name/address resolution from the perspective of the OS instead of relying solely on the DNS like the dig or host commands. If this makes sense and sounds useful, just go check out my resolve-pl repository on github. If it doesn’t fully make sense, then read on.
Are you annoyed that there are no native Linux packages for the AWS CLI (deb, rpm…)? And, thus, no repositories? I am, a bit.
But it’s also true that the installation is not difficult at all, right? Well, yes, if you want to install it in locations different than the defaults (e.g. your user’s home directory) and on more than one machine you still have to do some work, but it’s not terrible, is it?
Then, one day, you find that one of the AWS CLI commands you need to use was added in a newer version than the one you are running, so you have to update the AWS CLI on all machines, and possibly rediscover the parameters you used during the initial installation. Are you happy with that?
If you find it useful, I am happy. And if you want to support more Linux distributions or more operating systems (MacOS should be fairly easy, I expect), just go ahead and throw me a pull request. Enjoy!
If you are a Linux user and you find yourself in need to connect to a remote Windows server desktop, I hereby recommend that you give Remmina a try.
At my new job I have to check into Windows servers at times (eh, I know, it’s a cruel world…) through the RDP protocol. We have some tooling available that, given the name of a VM, will look up from various sources all information necessary to connect to that machine and build a Remote Desktop Connection file (“.rdp”). The problem: Vinagre, the standard GNOME RDP client, doesn’t know what to do with that file, so I had to find another client.
Just a small bash snippet for those cases where, for example, a command returns AWS instance IDs but not the matching DNS names or an IP addresses. The function id2dns, that you can add to your .bashrc file, will do the translation for you. In order to use the function you will:
ensure you have the aws CLI installed and functional;
ensure you have jq command available;
ensure you have valid AWS credentials set, so that your aws CLI will work.
This is mostly a note to self. When I need an EC2 instance to run a quick test, it may be overly annoying to provision one through the web console, or it may feel a bit overkill to do that using large frameworks like terraform. Using the AWS command line is just fine, if you know what command to run with which parameters, and it pays off quickly if, to run your tests, you use the settings often (AMI, subnet, security groups…) or if during the same test session you need to scrap and rebuild test instances a few times. Here is an example on how to do so with the AWS command line client.
Say you have access to two separate AWS accounts, and say you have EC2 instances running in a certain region and availability zone, e.g eu-west-1a, in both accounts. Today I learned to my greatest surprise that, despite the same name, they may actually be two totally different locations. Intrigued? Read on!