One to read: “Tyblog | Systemd for (Impatient) Sysadmins”
The two parts about this post which interest me the most are about timers (a replacement for Cron, perhaps?) and User Instances (likewise, a replacement for how I use Cron :) ). There’s other interesting stuff here, but this is the crux of it for me!
This blog post was found via cron.weekly #89.
Wow, now there’s a specific post title…
I use Ansible… quite a bit :) and one of the things I do with Ansible is to have a standard build desktop that I can create using Vagrant. Recently I upgraded the base to Ubuntu 18.04, and it annoyed me that I still didn’t have a working keyboard combination, so I kept getting US keyboards. I spent 20 minutes sorting it out, and here’s how to do it.
- name: Set keyboard layout
debconf:
name: "keyboard-configuration"
question: "keyboard-configuration/{{ item.key }}"
value: "{{ item.value }}"
vtype: "{{ item.type|default('string') }}"
with_items:
- { key: "altgr", value: "The default for the keyboard layout", vtype: "select" }
- { key: "compose", value: "No compose key", vtype: "select" }
- { key: "ctrl_alt_bksp", value: "false", type: "boolean" }
- { key: "variant", value: "English (UK)", vtype: "select" }
- { key: "layout", value: "English (UK)", vtype: "select" }
- { key: "model", value: "Generic 105-key PC (intl.)", vtype: "select" }
I posted how I got to this point over at the Server Fault post that got me most of the way. https://serverfault.com/a/912342/14832
One to read: “It’s Time to Retire “RTFM” – Compassionate Coding – Medium”
This was automatically posted from my RSS Reader, and may be edited later to add commentary.
One to read: “Interns with toasters: how I taught people about load balancers”
This was automatically posted from my RSS Reader, and may be edited later to add commentary.
One to read: “How to undo (almost) anything with Git | The GitHub Blog”
This was automatically posted from my RSS Reader, and may be edited later to add commentary.
One to read: “Debian & Ubuntu Equivalents of ‘yum whatprovides’”
This was automatically posted from my RSS Reader, and may be edited later to add commentary.
For those of you who are working with #Ansible… Ansible 2.5 is out, and has an unusual documentation change around a key Ansible concept – `with_` loops Where you previously had:
with_dict: "{{ your_fact }}"
or
with_subelements:
- "{{ your_fact }}"
- some_subkey
This now should be written like this:
loop: "{{ lookup('dict', your_fact) }}"
and
loop: "{{ lookup('subelements', your_fact, 'some_subkey') }}"
Fear not, I hear you say, It’s fine, of course the documentation suggests that this is “how it’s always been”…… HA HA HA Nope. This behaviour is new as of 2.5, and needs ansible to be updated to the latest version. As far as I can tell, there’s no way to indicate to Ansible “Oh, BTW, this needs to be running on 2.5 or later”… so I wrote a role that does that for you.
ansible-galaxy install JonTheNiceGuy.version-check
You’re welcome :)
More useful URLs:
https://hackablepodcast.com/#/episodes/and-were-in
If you’ve ever wondered why you’re encouraged to use different passwords on every website, here’s a perfect example. In this episode from Cybersecurity Firm McAfee, a not-very-technical presenter asks a Penetration Tester (someone who is paid to breach a client’s own security to prove where it’s weaknesses are) to show how easy or hard it is to get into his accounts… In the end the tester goes after this presenter’s Dad’s account… and gets into his Amazon account and his Facebook account in only a couple of minutes.
He also explains some things you can do to keep an eye on these things for yourself. In general this is a fantastic podcast to listen to, and I’d strongly suggest you subscribe to it because it’s not too over-the-top, it’s not pitched at the techno-nerds (like me ;) ) it’s just … right.
This post came about after a couple of hours of iterations, so I can’t necessarily quote all the sources I worked from, but I’ll do my best!
In OpenStack (particularly in the “Kilo” release I’m working with), if you have a networking device that will pass traffic on behalf of something else (e.g. Firewall, IDS, Router, Transparent Proxy) you need to tell the virtual NIC that the interface is allowed to pass traffic for other IP addresses, as OpenStack applies by default a “Same Origin” firewall rule to the interface. Defining this in OpenStack is more complex than it could be, because for some reason, you can’t define 0.0.0.0/0 as this allowed address pair, so instead you have to define 0.0.0.0/1 and 128.0.0.0/1.
Here’s how you define those allowed address pairs (note, this assumes you’ve got some scaffolding in place to define things like “network_appliance”):
allowed_address_pairs: "{% if (item.0.network_appliance|default('false')|lower() == 'true') or (item.1.network_appliance|default('false')|lower() == 'true') %}[{'ip_address': '0.0.0.0/1'}, {'ip_address': '128.0.0.0/1'}]{% else %}{{ item.0.allowed_address_pairs|default(omit) }}{% endif %}"
OK, so we’ve defined the allowed address pairs! We can pass traffic across our firewall. But (and there’s always a but), the product I’m working with at the moment has a floating MAC address in a cluster, when you define an HA pair. They have a standard schedule for how each port’s floating MAC is assigned… so here’s what I’ve ended up with (and yes, I know it’s a mess!)
allowed_address_pairs: "{% if (item.0.network_appliance|default('false')|lower() == 'true') or (item.1.network_appliance|default('false')|lower() == 'true') %}[{'ip_address': '0.0.0.0/1'},{'ip_address': '128.0.0.0/1'}{% if item.0.ha is defined and item.0.ha != '' %}{% for vdom in range(0,40, 10) %},{'ip_address': '0.0.0.0/1','mac_address': '{{ item.0.floating_mac_prefix|default(item.0.image.floating_mac_prefix|default(floating_mac_prefix)) }}:{% if item.0.ha.group_id|default(0) < 16 %}0{% endif %}{{ '%0x' | format(item.0.ha.group_id|default(0)|int) }}:{% if vdom+(item.1.interface|default('1')|replace('port', '')|int)-1 < 16 %}0{% endif %}{{ '%0x' | format(vdom+(item.1.interface|default('1')|replace('port', '')|int)-1) }}'}, {'ip_address': '128.0.0.0/1','mac_address': '{{ item.0.floating_mac_prefix|default(item.0.image.floating_mac_prefix|default(floating_mac_prefix)) }}:{% if item.0.ha.group_id|default(0) < 16 %}0{% endif %}{{ '%0x' | format(item.0.ha.group_id|default(0)|int) }}:{% if vdom+(item.1.interface|default('0')|replace('port', '')|int)-1 < 16 %}0{% endif %}{{ '%0x' | format(vdom+(item.1.interface|default('1')|replace('port', '')|int)-1) }}'}{% endfor %}{% endif %}]{% else %}{{ item.0.allowed_address_pairs|default(omit) }}{% endif %}"
Let's break this down a bit. The vendor says that each port gets a standard prefix, (e.g. DE:CA:FB:AD) then the penultimate octet is the "Cluster ID" number in hex, and then the last octet is the sum of the port number (zero-indexed) added to a VDOM number, which increments in 10's. We're only allowed to assign 10 "allowed address pairs" to an interface, so I've got the two originals (which are assigned to "whatever" the defined mac address is of the interface), and four passes around. Other vendors (e.g. this one) do things differently, so I'll probably need to revisit this once I know how the next one (and the next one... etc.) works!
So, we have here a few parts to make that happen.
The penultimate octet, which is the group ID in hex needs to be two hex digits long, and without adding more python modules to our default machines, we can't use a "pad" filter (to add 0's to the beginning of the mac octets), so we do that by hand:
{% if item.0.ha.group_id|default(0) < 16 %}0{% endif %}
And here's how to convert the group ID into a hex number:
{{ '%0x' | format(item.0.ha.group_id|default(0)|int) }}
Then the next octet is the sum of the VDOM and PortID. First we need to loop around the VDOMs. We don't always know whether we're going to be adding VDOMs until after deployment has started, so here we will assume we've got 3 VDOMs (plus VDOM "0" for management) as it doesn't really matter if we don't end up using them. We create the vdom variable like this:
{% for vdom in range(0, 40, 10) %} STUFF {% endfor %}
We need to put the actual port ID in there too. As we're using a with_subelement loop we can't create an increment, but what we can do is ensure we're recording the interface number. This only works here because the vendor has a sequential port number (port1, port2, etc). We'll need to experiment further with other vendors! So, here's how we're doing this. We already know how to create a hex number, but we do need to use some other Jinja2 filters here:
{{ '%0x' | format(vdom+(item.1.interface|default('1')|replace('port', '')|int)-1) }}
Let's pull this apart a bit further. item.1.interface is the name of the interface, and if it doesn't exist (using the |default('1') part) we replace it with the string "1". So, let's replace that variable with a "normal" value.
{{ '%0x' | format(vdom+("port1"|replace('port', '')|int)-1) }}
Next, we need to remove the word "port" from the string "port1" to make it just "1", so we use the replace filter to strip part of that value out. Let's do that:
{{ '%0x' | format(vdom+("1"|int)-1) }}
After that, we need to turn the string "1" into the literal number 1:
{{ '%0x' | format(vdom+1-1) }}
We loop through vdom several times, but let's pick one instance of that at random - 30 (the fourth iteration of the vdom for-loop):
{{ '%0x' | format(30+1-1) }}
And then we resolve the maths:
{{ '%0x' | format(30) }}
And then the |format(30) turns the '%0x' into the value "1e"
Assuming the vendor prefix is, as I mentioned, 'de:ca:fb:ad:' and the cluster ID is 0, this gives us the following resulting allowed address pairs:
[
{"ip_address": "0.0.0.0/1"},
{"ip_address": "128.0.0.0/1"},
{"ip_address": "0.0.0.0/1", "mac_address": "de:ca:fb:ad:00:00"},
{"ip_address": "128.0.0.0/1", "mac_address": "de:ca:fb:ad:00:00"},
{"ip_address": "0.0.0.0/1", "mac_address": "de:ca:fb:ad:00:0a"},
{"ip_address": "128.0.0.0/1", "mac_address": "de:ca:fb:ad:00:0a"},
{"ip_address": "0.0.0.0/1", "mac_address": "de:ca:fb:ad:00:14"},
{"ip_address": "128.0.0.0/1", "mac_address": "de:ca:fb:ad:00:14"},
{"ip_address": "0.0.0.0/1", "mac_address": "de:ca:fb:ad:00:1e"},
{"ip_address": "128.0.0.0/1", "mac_address": "de:ca:fb:ad:00:1e"}
]
I hope this has helped you!
Sources of information: