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 :)
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)
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!
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!
I am building Openstack Servers with the ansible os_server module. One of these fields will accept a very long string (userdata). Typically, I end up with a giant blob of unreadable build script in this field…
Today I learned that I can use this:
---
- name: "Create Server"
os_server:
name: "{{ item.value.name }}"
state: present
availability_zone: "{{ item.value.az.name }}"
flavor: "{{ item.value.flavor }}"
key_name: "{{ item.value.az.keypair }}"
nics: "[{%- for nw in item.value.ports -%}{'port-name': '{{ ProjectPrefix }}{{ item.value.name }}-Port-{{nw.network.name}}'}{%- if not loop.last -%}, {%- endif -%} {%- endfor -%}]" # Ignore this line - it's complicated for a reason
boot_volume: "{{ ProjectPrefix }}{{ item.value.name }}-OS-Volume" # Ignore this line also :)
terminate_volume: yes
volumes: "{%- if item.value.log_size is defined -%}[{{ ProjectPrefix }}{{ item.value.name }}-Log-Volume]{%- else -%}{{ omit }}{%- endif -%}"
userdata: "{% include 'templates/userdata.j2' %}"
auto_ip: no
timeout: 65535
cloud: "{{ cloud }}"
with_dict: "{{ Servers }}"
This file (/path/to/ansible/playbooks/servers.yml) is referenced by my play.yml (/path/to/ansible/play.yml) via an include, so the template reference there is in my templates directory (/path/to/ansible/templates/userdata.j2).
That template can also then reference other template files itself (using {% include 'templates/some_other_file.extension' %}) so you can have nicely complex userdata fields with loads and loads of detail, and not make the actual play complicated (or at least, no more than it already needs to be!)
Recently, I have used K5, which is an instance of OpenStack, run by Fujitsu (my employer). To do some of the automation tasks I have played with both python-openstackclient and Ansible. This post is going to cover how to get those tools to work with K5.
I have access to a Linux virtual machine (Ubuntu 16.04) and the Windows Subsystem for Linux in Windows 10 to run “Bash on Ubuntu on Windows”, and both accept the same set of commands.
In order to run these commands, you need a couple of dependencies. Your mileage might vary with other Linux distributions, but, for Ubuntu based distributions, run this command:
sudo apt install python-pip build-essential libssl-dev libffi-dev python-dev
Next, use pip to install the python modules you need:
sudo -H pip install shade==1.11.1 ansible cryptography python-openstackclient
If you’re only ever going to be working with a single project, you can define a handful of environment variables prefixed OS_, like this:
export OS_USERNAME=BloggsF
export OS_PASSWORD=MySuperSecretPasswordIsHere
export OS_REGION_NAME=uk-1
export OS_USER_DOMAIN_NAME=YourProjectName
export OS_PROJECT_NAME=YourProjectName-prj
export OS_PROJECT_ID=baddecafbaddecafbaddecafbaddecaf
export OS_AUTH_URL=https://identity.uk-1.cloud.global.fujitsu.com/v3
export OS_VOLUME_API_VERSION=2
export OS_IDENTITY_API_VERSION=3
But, if you’re working with a few projects, it’s probably worth separating these out into clouds.yml files. This would be stored in ~/.config/openstack/clouds.yml with the credentials for the environment you’re using:
---
clouds:
root:
identity_api_version: 3
regions:
- uk-1
auth:
auth_url: https://identity.uk-1.cloud.global.fujitsu.com/v3
password: MySuperSecretPasswordIsHere
project_id: baddecafbaddecafbaddecafbaddecaf
project_name: YourProjectName-prj
username: BloggsF
user_domain_name: YourProjectName
Optionally, you can separate out the password, username or any other “sensitive” information into a secure.yml file stored in the same location (removing those lines from the clouds.yml file), like this:
---
clouds:
root:
auth:
password: MySuperSecretPasswordIsHere
Now, you can use the Python based Openstack Client, using this invocation:
openstack --os-cloud root server list
Alternatively you can use the Ansible Openstack (and K5) modules, like this:
---
tasks:
- name: "Authenticate to K5"
k5_auth:
cloud: root
register: k5_auth_reg
- name: "Create Network"
k5_create_network:
name: "Public"
availability_zone: "uk-1a"
state: present
k5_auth: "{{ k5_auth_reg.k5_auth_facts }}"
- name: "Create Subnet"
k5_create_subnet:
name: "Public"
network_name: "Public"
cidr: "192.0.2.0/24"
gateway_ip: "192.0.2.1"
availability_zone: "uk-1a"
state: present
k5_auth: "{{ k5_auth_reg.k5_auth_facts }}"
- name: "Create Router"
k5_create_router:
name: "Public"
availability_zone: "uk-1a"
state: present
k5_auth: "{{ k5_auth_reg.k5_auth_facts }}"
- name: "Attach private network to router"
os_router:
name: "Public"
state: present
network: "inf_az1_ext-net02"
interfaces: "Public"
cloud: root
- name: "Create Servers"
os_server:
name: "Server"
availability_zone: "uk-1a"
flavor: "P-1"
state: present
key_name: "MyFirstKey"
network: "Public-Network"
image: "Ubuntu Server 14.04 LTS (English) 02"
boot_from_volume: yes
terminate_volume: yes
security_groups: "Default"
auto_ip: no
timeout: 7200
cloud: root
My new job means I’m currently building a lot of test boxes with Ansible, particularly OpenStack guests. This means I’m trying to script as much as possible without actually … getting my hands dirty with the actual “logging into it and running things” perspective.
This week, I hit a problem standing up a popular firewall vendor’s machine with Ansible, because I was trying to bypass the first-time-wizard… anyway, it wasn’t working, and I couldn’t figure out why. I talked to my colleague [mohclips] and he eventually told me that I needed to use a template, because what I was trying to do was too complicated.
But, damn him, I knew that wasn’t the answer :)
Anyway, I found this comment on a ticket, which lead me to the following… if you’re finding that your userdata: variable in the os_server module of Ansible isn’t working, you might need to wrap it up like this:
userdata: |
{%- raw -%}#!/bin/bash
# Kill script if the pipe fails
set -euf -o pipefail
# Write everything from this point on to Syslog
echo " == Set admin credentials == "
clish -c 'set user admin password-hash {% endraw -%}{{ default_password|password_hash('sha512') }}{%- raw -%}' -s
{% endraw %}
Note that, if you have a space before your variable, use {% endraw -%} and if you’ve a space after it, use {%- raw %} as the hyphen means “ditch all the spaces before/after this command”.
Here is a transcript of a talk by Allison Parrish at the Open Hardware Summit in Portland, OR. The talk “Programming is Forgetting: Toward a New Hacker Ethic” is a discussion about the failings of the book “Hackers” by Steven Levy. Essentially, that book proposed (in the 80’s) a set of ethics for Hackers (which is to say, creative programmers or engineers, not malicious operators). Allison suggests that many of the parables in the book do not truly reflect the “Hacker Ethic”, and revises them for today’s world.
Her new questions (not statements) are as follows:
This is a significant re-work of the original “Hacker Ethic“, and you should really either watch or read the talk to see how she got to these from the original, especially as it’s not as punchy as the original.
I’d like to think I was thinking of things like these questions when I wrote CampFireManager and CCHits.
I have an Acer V5-171 laptop, with a BCM43228 802.11a/b/g/n wireless network adaptor. In Ubuntu 12.04 and 12.10, I had absolutely no issues with my wireless connectivity. I upgraded to Ubuntu 13.04, and the wifi device dropped out.
I fixed the wifi by performing the following command (found via this forum post):
sudo apt-get install --reinstall bcmwl-kernel-source
I’d had a few issues with my Ubuntu install – mostly due to tinkering, so I thought I’d give a few other distributions a shot. Unfortunately, the state of the support of this driver was even worse on the others I installed.
Sabayon 13.04 (note, this is from memory!): You need to edit /etc/modprobe.d/blacklist.conf and uncomment the blacklisting of the b43 module. You need to comment the blacklisting of the 5 or so modules above it (mostly to enable the “wl” module). While this brought the NIC up, it didn’t survive an upgrade of packages, and by this point I’d spent about 2 days on it, so I was getting ratty, and wanted to try something else.
Fedora 18: Also didn’t work – I checked this distro because of my issues with Sabayon, but I figured that as it wasn’t working, perhaps there was something fundamental going on – probably either installing a package, or blacklisting a module would have solved this – I won’t know now!
OpenSUSE 12.3: I finally settled on installing OpenSUSE after I’d realised my issues were just with the module and not the distribution. I’d considered running OpenSUSE for some time and thought I’d give it a shot. I found a post (which I’ve subsequently lost) which showed that the package wasn’t installed by default to support this adaptor, so I found this page which listed both the relevant kernel module (in my case the x86_64 12.3 package) and the matching software package. As I was doing the install semi-offline (I can’t tether my phone to the laptop right now, and had no wired access) I transferred the relevant RPMs over, and installed them using rpm (the RedHat/Fedora/OpenSUSE/etc package manager). Wireless came up, but I’m missing certain APs – probably a configuration item that I’ve not yet fixed. It’s not disastrous, but is annoying :)
This is a pretty quick technical post explaining how to get vhost_alias working with apache2 on Ubuntu 12.10. Read More