Upgrading Linux Containers from Debian Wheezy to Jessie

 Linux, Working Notes  No Responses »
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.

Always Check Your DNS Resolver (/etc/resolv.conf)

 Linux, Working Notes  No Responses »
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).

 

An Awesome Custom Help Screen

 Computing, Linux, Working Notes  No Responses »
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 dillo. Turns 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 :-

2015-03-07_1457

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

My Triangle Is More Secure Than Your Penny Whistle

 Computing, Security  No Responses »
Feb 282015
 

This is a little rant about those people who feel the need to jump on every announcement of a security issue with Linux or Windows, and claim their favourite operating system is more secure. These days such rants are little more than fanboyism, and childish at that. 

I'm an old Unix guy (and thus am into Linux rather than Windows), and in the past did used to ramble on about how insecure Windows was. And Windows used to be a complete disaster area when it came to security.

But that has changed. Whilst I'm still not a big Windows fan, the security of Windows itself has improved to the point where it's not too bad.

Of course there are plenty of software vendors out there who are completely clueless when it comes to security, so any time you add some piece of cool corporate software to a Linux or Windows server you're running a big risk. 

But back to the haters. 

The most irritating thing about the whole 'my operating system is more secure than your operating system' is a simplistic comparison of Linux and Windows. They are not directly comparible. – simply counting the number of security vulnerabilities in "Linux" and "Windows" is an overly simplistic comparson.

First of all, Linux has many more components than Windows; partally because Linux tends to throw in the kitchen sink, and partially because of a different philosophy – the "Unix way" is to build many small tools rather than one big tool. But just because Linux includes tons of stuff, doesn't make insecurities in all that stuff a problem on your server – for example, none of my web servers have a web browser installed so all those hundreds of web browser bugs are irrelevant to my servers. 

Windows itself has caught onto the trick that has been standard practice for decades – only install the stuff you actually need. Whilst there are popular Linux distributions that do the same thing (Debian, and Ubuntu amonst others), there are still some that tend to install far too much (RedHat, SLES, etc.).

Secondly the number of vulnerabliities does not take into account how serious each vulnerability is. Ten privilege escalation vulnerabilities comes nowhere close to a shellshock. 

When you come down to it, the choice of which operating system to run has less of an effect on how vulmerable your server is than who runs your server. A tightly controlled Windows server that is patched often and well configured is far more secure than a Linux server that is patched when installed (if then!) and then left alone by an administrator who assumes that "out of the box" configurations are suitable.

Labelling a FAT Filesystem

 Computing, Linux, Working Notes  No Responses »
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!

 Older Entries  Newer Entries