No ads? Contribute with BitCoins: 16hQid2ddoCwHDWN9NdSnARAfdXc2Shnoa
Nov 142015

I am obviously doing something wrong because computers are not supposed to behave like this, but my Linux containers (despite previous attempts) are booting with IPv6 privacy addresses randomly :-

✓ root@pica» lxc-ls --fancy | grep chagers
chagers   RUNNING  2001:8b0:ca2c:dead::5e11, 2001:8b0:ca2c:dead:f42b:6dff:fe16:2f2d  YES        
✓ root@pica» lxc-stop --name chagers; lxc-start --daemon --name chagers
✓ root@pica» lxc-ls --fancy | grep chagers
chagers   RUNNING  2001:8b0:ca2c:dead:206b:70ff:fe45:7242, 2001:8b0:ca2c:dead::5e11  YES        
✓ root@pica» lxc-stop --name chagers; lxc-start --daemon --name chagers
✓ root@pica» lxc-ls --fancy | grep chagers
chagers   RUNNING  2001:8b0:ca2c:dead::5e11                                         YES        

That is not how computers are supposed to behave!damascus-unix-prompt

Oct 032015

One thing that has always puzzled me about Linux Containers was why it is necessary to configure the network address in two places – the container configuration, and the operating system configuration. The short answer is that it isn't.

If you configure network addresses statically within the container configuration :-

» grep net /var/lib/lxc/mango/config 
# networking = veth = up = br0 = = =         2001:0db8:ca2c:dead:0000:0000:0000:000a/64 = 2001:0db8:ca2c:dead:0000:0000:0000:0001

Then the configuration within the container's operating system can simply be :-

» cat /var/lib/lxc/mango/rootfs/etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
iface eth0 inet6 manual

And that works fine.

Oct 032015

One of the things that has been mildly irritating me about my little collection of Linux containers has been that in addition to the statically defined IPv6 addresses, there is also an automatically defined IPv6 address :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                                                              AUTOSTART  
apricot   RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  2001:db8:ca2c:dead:804a:bfff:fe83:f98d, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:65, 2001:db8:ca2c:dead::cafe     YES        
mango     RUNNING  2001:db8:ca2c:dead:6c42:24ff:fe7d:4e9, 2001:db8:ca2c:dead::a      YES        
peach     RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:68, 2001:db8:ca2c:dead::3a11     YES        
rhubarb   RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:69, 2001:db8:ca2c:dead::dead     YES  

Now this is hardly the end of the world, but it is not tidy and it is the sort of thing that may lead to problems down the road if servers are communicating on an address that is not reverse DNS registered. Or indeed when someone contacts a server on an address such as 2001:db8:ca2c:dead::3eb and the reply comes from 2001:db8:ca2c:dead:21e:a0ff:feb6:6a.

After any number of false starts, the answer is quite simple – use sysctl to turn off autoconfigured address from within the container; which doesn't make much sense logically – containers don't have a kernel of their own, so the global kernel should be the one that is tuned. However :-

for container in $(lxc-ls)
  echo net.ipv6.conf.eth0.autoconf = 0 >> /var/lib/lxc/$container/rootfs/etc/sysctl.conf

Does the trick (after a reboot)  :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                                                              AUTOSTART  
apricot   RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  2001:db8:ca2c:dead:18d9:99ff:fe28:3591, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  2001:db8:ca2c:dead::cafe                                          YES        
mango     RUNNING  2001:db8:ca2c:dead:2411:80ff:feb9:6600, 2001:db8:ca2c:dead::a     YES        
peach     RUNNING  2001:db8:ca2c:dead::3a11                                          YES        
rhubarb   RUNNING  2001:db8:ca2c:dead::dead                                          YES        

Except for the older containers 🙁 

I've obviously missed something, but fixing nearly half of the containers is a good start.

After attending to pending upgrades (some of my old containers were still running wheezy), and setting the network configuration to manual, one of the recalictrant containers (glanders) lost it's autoconfigured address. 

Two more containers lost their unwanted extra addresses after "fixing" their configuration. I'm not sure what was wrong with the old configuration, but after copying and modifying a recently created container configuration, they rebooted with just one IPv6 address. The last one was mango, but after an extra reboot, it also was fixed :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                      AUTOSTART  
apricot   RUNNING  2001:db8:ca2c:dead::3eb   YES        
chagers   RUNNING  2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  2001:db8:ca2c:dead::ba11  YES        
lyme      RUNNING  2001:db8:ca2c:dead::cafe  YES        
mango     RUNNING  2001:db8:ca2c:dead::a     YES        
peach     RUNNING  2001:db8:ca2c:dead::3a11  YES        
rhubarb   RUNNING  2001:db8:ca2c:dead::dead  YES        
May 222015

So on my upgrade from Wheezy to Jessie, I found myself (amongst other issues) looking at a graphical interface where the mouse worked fine, but no mouse pointer was visible. After trying a few other things, it turned out that :-

gsettings set org.gnome.settings-daemon.plugins.cursor active false

Did the trick.

Of course that tip came from somewhere else, but as it worked for me, it’s worth making a note of.

May 022015

I have recently been upgrading my Linux containers from Debian wheezy to jessie, and each time have encountered a problem preventing the container from booting. Or rather as it turns out, preventing the equivalent of init from starting any daemons. Which is systemd of course.

Now this is not some addition to the Great Systemd Debate (although my contribution to that debate may well arrive someday), but a simple fix, or at this stage a workaround (to use the dreaded ITIL phrase).

The fix is to re-install the traditional SystemV init package replacing the new systemd package. This can be done during the upgrade by running the following at the end of the usual process :-

apt-get install sysvinit-core

Of course you will probably be reading this after you have encountered the problem. There are probably many ways of dealing with the situation after you have tried rebooting and encountered this issue, but my choice is to run the following commands from what I tend to call the "global container" :-

chroot ${container root filesystem}
apt-get install sysvinit-core

As mentioned before, this is not a fix. And indeed the problem may be my own fault – perhaps it doesn't help having the "global container" still running wheezy. Perhaps there are some instructions in the Debian upgrade manual that details some extra step you should run. And of course by switching back to System V init, we are missing out on all of the systemd fun.

Apr 252015

So for ages I've been having these mysterious slow downs in connecting to some of my internal servers. A few seconds, but once connected things are working normally.

And of course I kept putting off having a look into the problem, because firstly I'm lazy, secondly there are other more interesting things to look at, and thirdly I'd already discounted the obvious (actually I'd "fixed" it but made certain assumptions). But it's finally time to have a look.

Now I said I'd earlier discounted the obvious but decided to have a look any way. The thing to remember is that when you connect to a server it almost always performs a DNS lookup on your network address, so a mysterious slow down could well indicate that DNS resolution is to blame. You could perform diagnostics to determine what the problem is, but in all the decades I've been solving issues with computers whenever a mysterious slow down has occurred when connecting over the network, then the problem has almost always been the DNS resolver.

Taking a look at /etc/resolv.conf on the relevant server (a Linux container), and I find the file has a nameserver within it that was retired several weeks ago! Fixing that solved the issue.

Lessons learnt :-

  1. Just because you have a centrally distributed /etc/resolv.conf that is automatically installed on all your home network doesn't mean to say that it is always automatically installed. My Linux containers don't get that centrally distributed file (which had been corrected!).
  2. Don't assume that it's not the obvious even if you have reasons for thinking it couldn't possibly be the obvious (see #1).


Mar 072015

So there I was, wandering down the street thinking about :-

  1. Sometimes being unable to remember custom key sequences that I've configured.
  2. That my "Help" button on my keyboard was unused.

And I thought that it would be fun to knock up a little application that would pop up a window and show a file. Then I got real, and realised that the application was already written and allowed fancy formatting of the help file(s) – it's called a browser.

Now for a whole bunch of reasons, you probably don't want to use a full blown browser, but something a little simpler and without any fancy controls, and I plumped for dilloTurns out that the "-f" flag turns off the fancy menu and toolbar, so what I needed was to persuade my window manager (Awesome) to run it when I pressed "Help" :-

	awful.key({ }, "Help", function () awful.util.spawn("dillo -f /home/mike/lib/help-files/index.html") end))

If you need help adding that to your Awesome configuration file, you're in the wrong place!

And of course it works :-


(And now of course I need to spend some time writing some help files!)

Feb 022015

Undocumented command options … grrr!

Every so often I find that I have a need to put a volume label onto a FAT filesystem – usually so a digital camera SD (or CF) card can be "automatically" mounted (actually they don't mount automatically on my workstation and I like it like that) in the right place. And of course every time I do, I remember that the command to do so is mlabel but I cannot remember exactly how to do it.

Because mlabel (together with the other mtools) has some sort of weird configuration file to turn Unix/Linux paths into drive letters‽ And yes that was an interribang although it could just as well be some other form of punctuation to express disgust instead. As it happens mlabel has an undocumented option to specify a device path … at least it doesn't appear in the usage hints :-

» mlabel -h
Mtools version 4.0.17, dated June 29th, 2011
Usage: mlabel [-vscVn] [-N serial] drive:

It turns out that there is a "-i" option which takes a device path, but you still have to specify the drive as "::" just so things are less likely to go right :-

» mlabel -i /dev/sdi1 ::
 Volume has no label
Enter the new volume label : LEICA1

And there it is!

Dec 222014

This is a series of working notes on the Yubikey which is an interesting device used to supplement passwords to make two-factor authentication easier. It is essentially a hardware security token device that pretends to your computer to be a keyboard and enters a one-time only password that can be used to verify your identity – much like a password, but much more secure.

Well perhaps "easier" only if someone does all the configuration for you, although I am inclined to look a bit deeper into such things for my own amusement. My own key is a Yubikey NEO, but much of what follows also applies to the other Yubikey models.


This is the spot for observations on using the Yubikey over time.

  1. For some reason the Yubikey doesn't always "light up" on my workstation at work. It works fine at home – the green light always turns on ready for a key press – but at work it often seems to flicker and stay out. Not sure what causes this, but it always seems to be persistent when you really need to use it! 


… is to some extent unnecessary, but under Linux there are three bits of software that can be installed to configure additional features of the Yubikey :-

  1. The library:
  2. The command-line tool:
  3. The GUI:

All three build easily from the instructions given. Just make sure to remember to copy the udev rules from yubikey-personalization to /etc/udev/rules.d/ and run udevadm trigger to enable them. This will make sure you can access your yubikey as a console user, so you don't have to become root.

Enabling Linux Authentication

This was all done with a Linux container (LXC), so it could be relatively easily thrown away and restarted. The first step was to install the relevant PAM module :-

# apt-get install libpam-yubico

This pulls in a ton of other required packages.

The next is to grab the unchanging part of your Yubikey token. This is the first 12 characters of what you get when you activate it. Whilst you have it to hand, now would be a good time to create the mapping file – /etc/yubikey-mappings :-

# Yubikey ID mappings
# Format:
#       user-id:yubikey-id:yubikey-id:...
# (But usually only one)

Next step is to add a little something to one of the pam files. For testing (assuming you have console) access, the relevant file might be /etc/pam.d/sshd but once you have things working, /etc/pam.d/common-auth might be a better choice. Right at the top of the file add :-

auth       sufficient debug id=16 authfile=/etc/yubikey-mappings
#       Added for Yubikey authentication.

Because these things always have problems when you first try them, it makes sense to set up the debugging log :-

touch /var/run/pam-debug.log
chmod a+w /var/run/pam-debug.log

At this point, assuming everything works as expected :-

  1. You will be able to authenticate using ssh using either your Yubikey, or your password.
  2. This assumes your server is able to communicate with the Yubi Cloud.

There are further improvements to be made … and we'll get to those shortly.

But That's Not Two-Factor Authentication!

Indeed not, so we'll fix that right now.

Firstly remove the line we previously added to /etc/pam.d/sshd; because of the way that Debian configures pam, it is less disruptive (i.e. fewer changes) to make the change to /etc/pam.d/common-auth :-

auth       requisite id=16 debug authfile=/etc/yubikey-mappings
#       Yubikey configuration added.
auth    [success=1 default=ignore] nullok_secure use_first_pass

But before restarting sshd (you have been doing that haven't you?), you will need to add a Yubikey ID to /etc/yubikey-mappings for the root user.

At this point, you will only be able to authenticate if you enter your username, followed by both your Unix password and activate your Yubikey at the password prompt. Entering both at the same prompt is a little weird especially when you consider that there is no indications anywhere that Yubikey authentication is required.

But we can fix that. First of all, one small change to common-auth – remove the use_first_pass phrase.

Next edit the file /etc/ssh/sshd_config and find the ChallengeResponseAuthentication phrase and set to "Yes" :-

ChallengeResponseAuthentication yes

And after a quick reboot, the log in process works in a sensible way :-

» ssh chagers
Yubikey for `mike': (Press YubiKey)
Password: (Enter Unix password)
Linux chagers 3.14-0.bpo.1-amd64 #1 SMP Debian 3.14.12-1~bpo70+1 (2014-07-13) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Dec 31 15:37:05 2014
Aug 272014

This post came about because HP (in their infinite wisdom) decided to make the web-based printer control all neat and tidy by aligning all of the IP columns and filling up the space with leading zeros. Spotted the problem yet?

Well you’re quicker than I was; although I had the advantage of knowing that something was wrong and that somebody had pasted that IP address with leading zeros, it took me a few seconds to wonder if it was just possible that leading zeros might be doing something “odd”.

The thing about IPv4 addresses (and IPv6 as well, but I’ll not be pasting in examples for those as they’re too long) is that they are not simply what we see on screen as (or whatever). That representation is converted into a 32-bit binary number which is used as the address. As an example :-

✓ mike@pica» ping -c 1
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=255 time=0.688 ms

--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.688/0.688/0.688/0.000 ms
✓ mike@pica» ping -c 1 167772161  
PING 167772161 ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=255 time=6.04 ms

--- 167772161 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.040/6.040/6.040/0.000 ms

As you can see, you do not have to use the conventional “dotted quad” representation; you can use the integer equivalent instead. You can also see why the “dotted quad” representation was invented!

To convert the “dotted quad” notation to an integer that can be used at the lowest level, certain calculations are performed. Either because of a peculiar clause in the original specifications of IPv4 addresses, or (and potentially more likely) as a side effect of one of the earliest implementations of IPv4, certain other representations are possible :-

✓ mike@pica» ping -c 1 0xa.0.0.1
PING 0xa.0.0.1 ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=255 time=1.34 ms

--- 0xa.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.341/1.341/1.341/0.000 ms
✓ mike@pica» ping -c 1
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=255 time=1.03 ms

--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.034/1.034/1.034/0.000 ms

As you can see, each individual octet (the numbers between the dots) can be represented in decimal (as we expect), in hexadecimal (by prepending “0x”), or most dangerously, octal (by prepending at least one “0”).

So an apparently innocuous IP address like will actually by converted into an integer that can be converted back into a more usual :-

✓ mike@pica» ping
PING ( 56(84) bytes of data.

There are several lessons to learn from this :-

  1. HP needs slapping with a really rotten haddock to make them realise that their printers have web interfaces that are unhelpful in the extreme.
  2. Leading zeros may be harmful, or at least may result in being slapped with a rotten haddock.
  3. Leading zeros in IP addresses indicate the use of octal and so the result may not be what you expect.
  4. Reading the screen can be helpful when diagnosing problems. It may be easy to miss, but there are clues enough to solve this little challenge even without knowing about octal.


WP Facebook Auto Publish Powered By :

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.