Let’s consider this simple playbook:

---
- hosts: node0
  vars:
    foo: ''
  tasks:
    - set_fact: foo='foo'
    - debug: var=foo

At first glance one would expect the foo variable to be set to the string value ‘foo’, but we get some strange result instead:

ok: [node0] => {
    "foo": "VARIABLE IS NOT DEFINED!"
}

Did ansible interpret the quoted foo as the foo variable and decided to unset the variable because it couldn’t deal with the recursion? In some other cases like setting a variable to itself in a vars: dictionary, an infinite loop error is thrown, not here.

Commenting out the set_fact task, we get the expected result:

ok: [node0] => {
    "foo": ""
}

Replacing ‘foo’ with ‘bar’ as a value in the set_fact task we get the following, which makes more sense:

ok: [node0] => {
    "foo": "bar"
}

But let’s say bar is also a variable, like this:

---
- hosts: node0
  vars:
    foo: ''
    bar: 'baz'
  tasks:
    - set_fact: foo='bar'
    - debug: var=foo

What should we expect here? ‘bar’ is not evaluated as a variable and the string value is used as is, so we get the same result as when bar was not defined.

When using double quotes, bar is expanded and the resulting value is ‘baz’, in the ‘foo’ case, we still get the same undefined message.

I couldn’t find a definitive statement anywhere in the documentation that would clarify the expansion rule for variables inside quoted statements. Are single quoted string supposed to be expanded or not? If so, is it now impossible to assign a variable it’s own name as a string?

I very much like Ansible, but this is a good example of how permissive syntax can shoot you right back in the foot. There are many ambiguities and tricky corner cases, sometimes due to functionalities delegated to some other piece of software involved (eg: yaml syntax limitations, reserved python keywords, jinja2 oddities, …).

In general, Ansible’s scoping model is perhaps too complex, with 16(!) levels of precedence and specificity, irregular definition mechanisms (eg: tasks can define vars, but not blocks? rly?), and subtle behavior oddities like the one highlighted here only amplifies that complexity. In simple cases this is not much of a problem, but when trying to create generic, truly reusable roles, it can cause many headaches, and in the long term can even be a thorn in Ansible’s side, as once this model gets adopted it will be hard to replace it with a clean design. This seems to be affecting pretty much any declaritive systems that start adding partial scripting capabilities. At first it’s just a bonus, then it becomes the reason you use it, and features are piled in to fill gaps as the need comes. At some point you have to wonder if it wouldn’t be a better idea to define a proper programming language from the ground up. An alternative starting point would be to use a language that is in itself it’s own input data, like Lisp or Scheme.

Here are a few other favorites:

Type mapping

Ansible gives you freedom of boole: yes,no,true,false,True,False! Not quite. Well, it depends…

---
- hosts: node0
  vars:
    foo: no
  tasks:
    - debug: msg='this is not the boolean you're looking for'
      when: foo == no

If we forget the fact that the when conditionals are actually jinja2 expressions (and the syntax helps us forget this so well), then we’d expect this playbook to work just fine, but no is undefined in jinja2, where booleans are true/false (although it now permits capitalized versions too).

Escaping strings

{{ }} can be used to expand a variable. What if you need a string with {{ }} in it?

---
- hosts: node0
  vars:
    foo: '{{ bar }}'
  tasks:
    - debug: var=foo

ok: [node0] => {
    "foo": "VARIABLE IS NOT DEFINED!"
}

Oups! As said above it seems that single quote statements are expanded (in some cases, not others, not by the same rules as double quoted string). The jinja2 syntax for escaping this is actually: "{% raw %}{{ bar }}{% endraw %}". Probably the most cumbersome escape syntax ever designed. (The liquid templates used in this blog too exhibit the same nonsense)

Oh, but wait, can I write this?

---
- hosts: node0
  vars:
    foo: "{% raw %}{% raw %}{{ bar }}{% endraw %}{% endraw %}"
  tasks:
    - debug: var=foo

fatal: [node0]: FAILED! => {"failed": true, "msg": "template error while templating string: Encountered unknown tag 'endraw'.. String: {% raw %}{% raw %}{{ bar }}{% endraw %}{% endraw %}"}

Of course that first endraw is in the way, but that’s going to make things complicated.

This post here explain how to escape the escape sequence. And we could avoid those unbalanced-looking braces by using this awful workaround:

{% assign oTag = '{%' %}
{% assign cP = '%' %}
{% assign cB = '}' %}
{{  oTag  }} raw {{ cP }}{{ cB }}{% raw %}{{ bar }}{% endraw %}{{  oTag  }} endraw {{ cP }}{{ cB }}

In all honesty, this is absolutely horrific. And you do not want to see the markdown for this bit. Another alternative in Liquid’s case is to use html entities, but that’s assuming your target is html at all.

Note that ‘%}’ had to be split into two variables because the parser captures the first ‘%}’ it sees no matter what context it encounters it in. Which causes the need to escape the escape sequence’s delimiter. This points to a rather inapropriate lexer being used, which perhaps was not intended for this type of work.

Blocks

The block documentation makes the following claim: Most of what you can apply to a single task can be applied at the block level. Apart from notable exceptions like one of the most desirable features for organizing your code, namely vars:, that statement holds up, but with a slight twist.

---
- hosts: node0
  vars:
    foo: true # let's use j2 compatible syntax :P
  tasks:
    - block:
      when: foo
      - debug: msg='not so fast mate...'

That should work right? Sadly, no, it doesn’t. Tasks can have when statements at the beginning, but not blocks. Which leads to some unfortunate situations:

---
- hosts: node0
  tasks:
    -block:
      - shell: /bin/do --some=stuff
        args:
          many='args'
          such='details'
          very='real world use case'
      - ...
      - ...
      - ...
      - ...
      - ...
      - ...
    when: very_lonely_down_here and not_quite_sure_im_aligned_right  

When reading a long list of tasks and blocks of tasks, the condition for which that item will play ought to be one of the first things on your mind.

No hard feelings here though, combining different tools together allows you to build impressive systems very quickly, albeit with some coherence collateral damage…

This is not very useful, but by running it with various parameters and seed one can notice some dead zones where very few values are produced (especially visible when using a 64x64 space division). Of course it is common knowledge that this PRNG is not cryptographically secure, and has otherwise very good properties for other uses. Nevertheless a bit of an intriguing curiosity.

This was originally posted in the previous version of this blog, so here it is again.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

#include <stdio.h>
#include <string.h>
#include <stdint.h>
#include <stdlib.h>
#include <math.h>
#include <signal.h>

#define MT_SIZE 624
#define GEN_OFST 397
#define INIT_K 0x6c078965

#define A 0x9908b0df
#define U 11
#define S 7
#define B 0x9d2c55680
#define T 15
#define C 0xefc60000
#define L 18

#define ESC 27
#define CLS() printf("%c[2J",ESC)
#define POS(row,col) printf("%c[%d;%dH",ESC,row,col)

uint32_t gMT[MT_SIZE];
uint16_t gIdx;

uint32_t gCount4096[65636];

typedef char Grid64[64][64][9];

static inline
void init_gen(uint32_t seed)
{
    uint32_t * __restrict mt = &gMT[0];
    const uint32_t *mte = mt + MT_SIZE;

    *(mt++) = seed;

    for (; mt!=mte; ++mt) {
        *mt = (INIT_K * (*(mt-1) ^ (*(mt-1)>>30))) & 0xffffffff;
    }
}

static inline
void gen_num()
{
    uint32_t * __restrict mt = &gMT[0];

    for (uint16_t i=0;i<MT_SIZE;++i) {
        const uint32_t y = (mt[i] & 0x80000000) + (mt[(i+1)%MT_SIZE] & 0x7ffffffff);
        mt[i] = mt[(i+GEN_OFST)%MT_SIZE] ^ (y<<1);
        if (y%2) {
            mt[i] = mt[i] ^ A;
        }
    }
}

static inline
uint32_t xtrct_num()
{
    if (!gIdx) {
        gen_num();
    }

    uint32_t y = gMT[gIdx];
    y ^= y>>U;
    y ^= y<<S & B;
    y ^= y<<T & C;
    y ^= y>>L;

    gIdx = (gIdx+1)%MT_SIZE;

    return y;
}

static inline
char *bin32(uint32_t val, char *buf)
{
    char *pbuf = buf;
    memset(pbuf,'0',33);
    pbuf += 33;
    *pbuf-- = '\0';
    while (val) {
        *pbuf-- = (val & 0x1)?'1':'0';
        val >>= 1;
    }
    return buf;
}


static inline
void cgrid6464_init(Grid64 buf)
{
    const char d[9] = "\e[2;30mo";

    for(int8_t i=31;i>=0;--i)
        for(int8_t j=63;j>=0;--j)
            for (int8_t k=8;k>=0;--k)
                buf[i][j][k] = d[k];
}

static inline
void cgrid6464_upd(uint32_t val, Grid64 buf)
{
    const uint16_t map =  val & 0xffff;
    const uint8_t row = ((map & 0x1f00) >> 8);
    const uint8_t col = (map & 0x3f);
    const uint16_t index = col*32+row;

    gCount4096[index] += 1;

    POS(row+1,col+1);

    const char d = buf[row][col][5] = '0'+((int)(log10f((float)gCount4096[index]))&0x7);

    printf("%c[1;3%cm%c",ESC,d,'0'+(int)(log10f((float)gCount4096[index])));
}

void cleanup()
{
    //FIXME: Resetting the cursor and clearing doesn't work. Probably due to interrupt inside printf.
    fflush(stdout);
    printf("%c[0m",ESC);
    CLS();
}

int main (int argc, char *argv[])
{
    uint32_t period = 0, num=0;
    char buf[33];
    Grid64 grid;
    int i = 0;
    gIdx = 0;

    memset(gMT,0x0,MT_SIZE*sizeof(uint32_t));
    memset(gCount4096,0x0,4096*sizeof(uint32_t));

    init_gen(0x2f9a109b);
    //init_gen(0x10000); // Very bad seed but if curious to see the process of recovery

    atexit(cleanup);

    CLS(); // Clear screen
    cgrid6464_init(grid);
    do {
        cgrid6464_upd(xtrct_num(),grid);
    } while (++period != 0);

    return 1;
}

The objective is simple: run a bash shell in a pid namespace with it’s own network namespace, bridged with the host’s network.

Running a shell in a new pid namespace

This is simple enough, use ‘unshare’ like this:

1
2
3

# unshare -fp --mount-proc
# pstree -p
bash(1)───pstree(114)

Adding a network namespace

In order to isolate the networking too, we can use ‘unshare’ with a new network namespace via the ‘ip’ command:

1
2

# ip netns add foo
# ip netns exec foo unshare -fp --mount-proc

You should now have an isolated bash process, with it’s own network stack:

1
2
3
4
5

# pstree -p
bash(1)───pstree(114)
# ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

Bridging the network

Network interfaces can only live in one namespace, in order to communicate between namespaces we can use veth device pairs which provide a sort of pipe behavior.

We can create a veth pair like this:

1

# ip link add veth-a type veth peer name veth-b

On my Debian Sid system this didn’t create ‘veth-b’, and subsequent commands failed with ‘Cannot find device “veth-b”’. So I had to issue the reciprocal command:

1

# ip link add veth-b type veth peer name veth-a

Now, we’ll assign one end of the veth pair to the ‘foo’ namespace:

1

# ip link set veth-b name eth0 netns foo

It should now appear under the ‘eth0’ name from inside our isolated bash shell. We can assign it an appropriate IP address normally with ‘ip addr add dev eth0’, and set a default route ‘ip route add default via dev eth0’.

On the host’s side, we now want to bridge ‘veth-a’ with ‘eth0’ in order for our little container to access the network.

Warning: this might break your host’s network temporarily.

1
2
3

# ip link add br0 type bridge
# ip link set eth0 master br0
# ip link set veth-a master br0

Make sure they are all in state UP, and we should be able to ping the outside world from our isolated namespace. Now, the hosts was probably setup to use ‘eth0’, and as it is now part of the bridge it will not work anymore. To get an equivalent setup, we’ll need to transfer the IPs assigned to ‘eth0’, to ‘br0’, and update our routing table. (I’m assuming a very simple setup here, e.g.: my laptop connected via ethernet with a static ip)

1
2
3
4

# ip addr del <ip> dev eth0
# ip add add <ip> dev br0
# ip route del default
# ip route add default via <gw_ip> dev br0

Now, your host’s networking should be back on track (actually, I had to bring interfaces down and back up for it work), and you can ping your host and isolated namespace transparently using their respective ip addresses. A thing of beauty.

Of course you probably don’t want to start setting up systems manually like this, but doing so does help me grasp a bit better how LXC, Docker and the like are working.

1

apt-get install hackrf gqrx-sdr gnuradio gr-osmosdr

It turns out that in the current state of Debian Sid/unstable, there a few confusing package dependencies as gqrx-sdr depends on libgnuradio-*3.7.5, and not the most recent 3.7.8 versions which are installed by the gnuradio package. Furthermore it also depends on libgnuradio-osmosdr0.1.3 which depends on some libboost packages which break with the recent libstdc++6 ABI change.

To get around this without too much recompile pain, one can install gnuradio 3.7.8 (+ gnuradio-dev) and manually compile libgnuradio-osmosdr, gr-osmosdr and gqrx-sdr.

As of yesterday, the latest revisions of osmocom and the 2.3.2 source of gqrx-sdr were compiling without issues.

I haven’t had a chance to test it much yet, will edit with more notes when I do.

EDIT: It works. Just make sure to have libhackrf-dev installed before compiling the osmosdr gnuradio extension, otherwise hackrf devices won’t show up in gqrx.

It started with a Linux amd64 VMWare disk image I wanted to load into VirtualBox and systematically got the following error:

1

VT-x is disabled in the BIOS. (VERR_VMX_MSR_VMXON_DISABLED).

Looking at the BIOS cpu config all virtualization options were enabled.

Of course the i5-M520 cpu on the X201 supports VT-x, SME, TXT and such…

1

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt aes lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid

And of course the VT-x flag was set in the VBox guest configuration…

Through all the forums and bug reports out there the closest I found was a Virtual Box bug report that got closed as “worksforme”. Very encouraging this was.

Some users with similar issues seemed to be able to function by using a prior VirtualBox version (< 4.3), but Oracle did not provide packages for Sid and the Wheezy package is not compatible with the latest kernels.

After giving up on BIOS upgrades due to flaky supposedly bootable ISOs from Lenovo I turned to KVM, assuming this was probably a VirtualBox issue.

But it turned out KVM would not work either. /dev/kvm would not be created and the following warnings showed up in syslog:

1
2

kvm: disable TXT in the BIOS or activate TXT before enabling KVM
kvm: disabled by bios

This confirmed for me that this was really a BIOS issue after all. I remembered seeing a reference to conflicts between Intel AMT and VT features in some Lenovo BIOSes, but AMT was definitely disabled and had been for ages.

Then I tried the following:

1. Enable AMT in the BIOS, and disable all virtualization options
2. Reboot, let the OS load, do a proper shutdown.
3. Disable AMT, re-enable virtualization options.
4. Reboot, and notice AMT being unconfigured.

At this point I had a /dev/kvm and was back in business.

It’s still unclear however weither there was some state confusion in the BIOS about the virtualization options, or with AMT, and if AMT was indeed conflicting.

And finally got around to re-style this space. Hopefully less retinas will be hurt in the future.