This is a quick post to remind me in the future… and is based on this official help page.
execute restore vmlicense tftp yourlicense.lic 192.0.2.1
This works around what you can do if you accidentally apply a license you’ve already applied somewhere else :)
CCHits was recently asked to move it’s media to another host, and while we were doing that we noticed that many of the Monthly shows were broken in one way or another…
Cue a massive rebuild attempt!
We already have a “ShowRunner” script, which we use with a simple Vagrant machine, and I knew you can use other hypervisor “providers”, and I used to use AWS to build the shows, so why not wrap the two parts together?
Firstly, I installed the vagrant-aws plugin:
vagrant plugin install vagrant-aws
Next I amended my Vagrantfile with the vagrant-aws values mentioned in the plugin readme:
Vagrant.configure(2) do |config|
config.vm.provider :aws do |aws, override|
config.vm.box = "ShowMaker"
aws.tags = { 'Name' => 'ShowMaker' }
config.vm.box_url = "https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box"
# AWS Credentials:
aws.access_key_id = "DECAFBADDECAFBADDECAF"
aws.secret_access_key = "DeadBeef1234567890+AbcdeFghijKlmnopqrstu"
aws.keypair_name = "TheNameOfYourSSHKeyInTheEC2ManagementPortal"
# AWS Location:
aws.region = "us-east-1"
aws.region_config "us-east-1", :ami => "ami-c29e1cb8" # If you pick another region, use the relevant AMI for that region
aws.instance_type = "t2.micro" # Scale accordingly
aws.security_groups = [ "sg-1234567" ] # Note this *MUST* be an SG ID not the name
aws.subnet_id = "subnet-decafbad" # Pick one subnet from https://console.aws.amazon.com/vpc/home
# AWS Storage:
aws.block_device_mapping = [{
'DeviceName' => "/dev/sda1",
'Ebs.VolumeSize' => 8, # Size in GB
'Ebs.DeleteOnTermination' => true,
'Ebs.VolumeType' => "GP2", # General performance - you might want something faster
}]
# SSH:
override.ssh.username = "ubuntu"
override.ssh.private_key_path = "/home/youruser/.ssh/id_rsa" # or the SSH key you've generated
# /vagrant directory - thanks to https://github.com/hashicorp/vagrant/issues/5401
override.nfs.functional = false # It tries to use NFS - use RSYNC instead
end
config.vm.box = "ubuntu/trusty64"
config.vm.provision "shell", path: "./run_setup.sh"
config.vm.provision "shell", run: "always", path: "./run_showmaker.sh"
end
Of course, if you try to put this into your Github repo, it’s going to get pillaged and you’ll be spending lots of money on monero mining very quickly… so instead, I spotted this which you can do to separate out your credentials:
At the top of the Vagrantfile, add these two lines:
require_relative 'settings_aws.rb'
include SettingsAws
Then, replace the lines where you specify a “secret”, like this:
aws.access_key_id = AWS_ACCESS_KEY
aws.secret_access_key = AWS_SECRET_KEY
Lastly, create a file “settings_aws.rb” in the same path as your Vagrantfile, that looks like this:
module SettingsAws
AWS_ACCESS_KEY = "DECAFBADDECAFBADDECAF"
AWS_SECRET_KEY = "DeadBeef1234567890+AbcdeFghijKlmnopqrstu"
end
This file then can be omitted from your git repository using a .gitignore file.
A few months ago I was a guest on The Ubuntu Podcast, where I mentioned that I use Streisand to terminate my VPN connections. I waffled and blathered a bit about how I set it up, but in the end it comes down to this:
streisand.vm.network "public_network", bridge: "eth0", ip: "192.0.2.1", :use_dhcp_assigned_default_route => false
streisand.vm.provision "shell", run: "always", inline: "ip route add 0.0.0.0/1 via 192.0.2.254 ; ip route add 128.0.0.0/1 via 192.0.2.254"
I’ve previously made mention of my addiction to Google Play Music… but I was called out recently, and asked about the script I used at the time. I’m sorry to say that I have had some issues with it, and instead, have resorted to using X forwarding. Here’s how I do it.
I create a user account for that other person (note, GMM will only let you upload to 3 accounts using this method. For any more, you’ll need a virtual machine!).
I then create an SSH public/private key with no passphrase.
ssh-keygen -b 2048 -N “” -C “$(whoami)@localhost” -f ~/.ssh/gmm.id_rsa
I write the public key into that new user’s .ssh/authorized_keys, by running:
ssh-copy-id -i ~/.ssh/gmm.id_rsa bloggsf@localhost
I will be prompted for the password of that account.
Finally, I create this script:
This is then added to the startup tasks of my headless-but-running-a-desktop machine.
Hello! Congratulations, you’ve been hacked! Oh, OK, that’s probably not how it feels, right?
You’ve probably just had a message from someone to say that your account has been messaging loads of people, or that there is stuff on your timeline that … well, you didn’t put there.
It’s OK. It happens to a LOT of people, because Facebook is a very clear target. Many many people spend large quantities of their life scrolling through the content on there, so it’s bound to be a target, and for some reason, they found your account.
So, first of all, let’s address how this probably happened.
It’s easier to do this from the Facebook website, but you can probably still do all this lot from a mobile device.
Let’s solve the first two. Go into the Facebook Security Settings page, where you should change your password and boot off any sessions that aren’t YOU right now (don’t worry if there’s LOADS there – if you’ve used your phone somewhere that’s not where you are now, Facebook stores it as a new session). You can always log back into those other sessions later if you need to.
The third one can be a bit time consuming: kicking off apps you don’t use (mine was like walking into a museum!). Head into the Facebook Apps Settings page, and start clicking the X buttons to remove the apps you don’t use. Every now and then you might get a message saying that there was an error removing one of those apps. It’s fine, just give it a second and then try again. If someone has got into your account because of one of the first two, it’s probably worth checking this part anyway just in case they did something else to your account than just sending spam…
You might also want to check out your timeline, and remove the messages you sent (if they were posted to your timeline) or contact people who have been messaged to let them know you lost control of your account.
If someone got into your email and started resetting passwords then you’ve got a much worse problem, and I can’t really go into it here, but, it’s probably best to say that if they were just after your Facebook account, you were REALLY lucky. Your email account typically has the ultimate reset code for *EVERY* account password, so it’s probably best to make sure that what I’m saying about Facebook is also true for your email provider!
If you’ve done the above, but you’ve picked a password you’ve used somewhere else before, then you’re kinda setting yourself up for this to happen to you again in the future.
You see, the way that most of these attacks happen is by someone getting hold of a password you’ve used on a less secure site, and then tried logging into your Facebook account with that password they’ve snaffled. Want to see how likely this is? Visit Have I Been Pwned and see if your details are in there (the chances are very very very high!) and you’ll see websites who have been breached in the past and had your details taken from there… and this is just “the ones we know about” – who knows how many other websites have been breached and we don’t know about!
You can prevent this by not using the same password everywhere. I know. It’s hard to think of a new password every time you come to a new website, and how will you remember that password the next time you get there? Well, fortunately, there’s a solution to this one – a password manager. It’s an application for your laptops, desktops and mobile devices that stores your password for you, and tells you about them when you go to login to a website.
What’s more, that password manager can create passwords for you, not like “BobIsMyBestFriend1988” but more like “za{UHCtqi3<6mC_j6TblSk3hwS” (which, unless you’re some kind of savant, you’ll never remember that)…. and then tell you about that in the future. So now, you only need to remember one password to get into the password manager, and it will tell you about everything else! So, that helps!
There are two ways to do this – run an add-on in your web browser and on your mobile devices which synchronises everything to the cloud for you, or run a separate app and synchronise those passwords yourself. Personally, as I’m a bit geeky, I’m happy doing the second, but most people reading this are probably going to want someone else to sort out the synchronising.
What if you accidentally gave your password to someone? Or if you went to a website that wasn’t actually the right page and put your password in there by mistake? Falling prey to this when it’s done on purpose is known as social engineering or phishing, and means that someone else has your password to get into your account.
To reduce the impact of something like this, we can force someone logging in to use a “second factor” – something you have, rather than something you know, sometimes referred to as “Two Factor” or “2FA”. You might already use something like this at work – either a card with a chip on it (called a “Smartcard”), a device you plug into the USB port on your computer, or a keyring style device with numbers on. Or… you might have an app on your phone.
If you want to set this up on Facebook, you’ll need to enable it. Take a look at their help page about this!
(And if you want to know about securing your email account, check out the “Docs” column on this site for instructions about many email providers)
Do you use Outlook for your email? Do you sometimes wish you could use a Kanban board with Outlook? Well, look no further!!
Thanks to an internal post about improving workflows, someone mentioned this git repo called “Outlook-Taskboard”, that gives you the ability to create and manipulate your Outlook tasks in a Kanban fashion.
Because it’s “just” native Outlook tasks, you can still manage them using the sidebar or the mobile apps, but when you get back to Outlook, you get to see their status and manage your tasks appropriately.
Do you use this pattern in your sh/bash/zsh/etc-sh scripts?
cat somefile | grep 'some string' | awk '{print $2}'
If so, you can replace that as follows:
cat somefile | awk '/some string/ {print $2}'
Or how about this?
grep -v 'something' < somefile | awk '{print $0}'
Try this:
awk '! /something/ {print $0}' < somefile
Ooo OK, how about if you want to get all actions performed by users when the ISO formatted dates (Y-m-d) match the first day of the month, but where you don’t want to also match January (unless you’re talking about the first of January)…
# echo 'BLOGGSF 2001-01-23 SOME_ACTION' | awk '$2 ~ /-01$/ {print $1, $3}'
(EMPTY LINE)
# echo 'BLOGGSF 2002-02-01 SOME_ACTION' | awk '$2 ~ /-01$/ {print $1, $3}'
BLOGGSF SOME_ACTION
This is so cool! Thanks to the tutorials “SKIP grep, use AWK” and the follow-up tutorials starting here…
Because of templates I was building in my post “Today I learned… Ansible Include Templates”, I thought you could repeat the same sections over again. Here’s a snippet of something like what I’d built (after combining lots of templates together):
#cloud-config
packages:
- iperf
- git
write_files:
- content: {% include 'files/public_key.j2' %}
path: /root/.ssh/authorized_keys
owner: root:root
permission: '0600'
- content: {% include 'files/private_key.j2' %}
path: /root/.ssh/id_rsa
owner: root:root
permission: '0600'
packages:
- byobu
write_files:
- content: |
#!/bin/bash
git clone {{ test_scripts }} /root/iperf_scripts
bash /root/iperf_scripts/run_test.sh
path: /root/run_test
owner: root:root
permission: '0700'
runcmd:
- /root/run_test
I’d get *bits* of it to run – basically, the last file, the last package and the last runcmd… but not all of it.
Turns out, cloud-init doesn’t like having to rebuild all the fragments together. Instead, you need to put them all together, so the write_files items, and the packages items all live in the same area.
Which, when you think about what it’s doing, which is that the parent lines are defining a variable called… well, whatever that line is, and if you replace it, it’s only going to keep the last one, then it all makes sense really!
Today I have been debugging why my Cloud-init scripts weren’t triggering on my Openstack environment.
I realised that something was wrong when I tried to use the noVNC console[1] with a password I’d set… no luck. So, next I ran a command to review the console logs[2], and saw a message (now, sadly, long gone – so I can’t even include it here!) suggesting there was an issue parsing my YAML file. Uh oh!
I’m using Ansible’s os_server module, and using templates to complete the userdata field, which in turn gets populated as cloud-init scripts…. and so clearly I had two ways to debug this – prefix my ansible playbook with a few debug commands, but then that can get messy… OR SSH into the box, and look through the logs. I knew I could SSH in, so the cloud-init had partially fired, but it just wasn’t parsing what I’d submitted. I had a quick look around, and found a post which mentioned debugging cloud-init. This mentioned that there’s a path (/var/lib/cloud/instances/$UUID/) you can mess around in, to remove some files to “fool” cloud-init into thinking it’s not been run… but, I reasoned, why not just see what’s there.
And in there, was the motherlode – user-data.txt…. bingo.
In the jinja2 template I was using to populate the userdata, I’d referenced another file, again using a template. It looks like that template needs an extra line at the end, otherwise, it all runs together.
Whew!
This does concern me a little, as I had previously been using this stanza to “simply” change the default user password to something a little less complicated:
#cloud-config
ssh_pwauth: True
chpasswd:
list: |
ubuntu:{{ default_password }}
expire: False
But now that I look at the documentation, I realise you can also specify that as a pre-hashed value (in which case, you would suffix that default_password item above with |password_hash('sha512')) which makes it all better again!
[1] If you run openstack --os-cloud cloud_a console url show servername gives you a URL to visit that has an HTML5 based VNC-ish client. Note the “cloud_a” and “servername” should be replaced by your clouds.yml reference and the server name or server ID you want to connect to.
[2] Like before, openstack --os-cloud cloud_a console log show servername gives you the output of the boot sequence (e.g. dmesg plus the normal startup commands, and finally, cloud-init). It can be useful. Equally, it’s logs… which means there’s a lot to wade through!
Thanks to my colleague Simon (@sipart on Twitter), I spotted this post (and it’s companion Github Repository) which explains how to do test-driven development in Ansible.
Essentially, you create two roles – test (the author referred to it as “validate”) and one to actually do the thing you want it to do (in the author’s case “add_vlan”).
In the testing role, you’d have the following layout:
/path/to/roles/testing/tasks/main.yml
/path/to/roles/testing/tasks/SOMEFEATUREtest.yml
In the main.yml file, you have a simple stanza:
---
- name: Include all the test files
include: "{{ outer_item }}"
with_fileglob:"/path/to/roles/validate/tasks/*test.yml"
loop_control: loop_var=outer_item
I’m sure that “with_fileglob” line could be improved to not actually need a full path… anyway
Then in your YourFeature_test.yml file, you do things like this:
---
- name: "Pseudocode in here. Use real modules for your testing!!"
get_vlan_config: filter_for=needle_vlan
register:haystack_var
- assert: that=" {{ needle_item }} in haystack_var "
When you run the play of the role the first time, the response will be “failed” (because “needle_vlan” doesn’t exist). Next do the “real” play of the role (so, in the author’s case, add_vlan) which creates the vlan. Then re-run the test role, your response should now be “ok”.
I’d probably script this so that it goes:
The benefit to doing it that way is that you “know” your tests aren’t running if the environment doesn’t have the “set_testing” thing in place, you get to run all your tests in a “clean room”, and then you clear it back down again afterwards, leaving it clear for the next pass of your automated testing suite.
Fun!