Planet HantsLUG

Syndicate content
Planet HantsLUG - http://hantslug.org.uk/planet/
Updated: 10 min 54 sec ago

Adam Trickett: Bog Roll: Wombat Upgrade

Wed, 18/11/2015 - 22:21

Today the order went in for a major rebuild of Wombat. Some parts will remain from the original, but overall most of the system will be replaced with more modern parts:

  • The new CPU has double the core count, higher clock speed and better features. It should be faster under both single and multi-threaded use. It should also use less electricity and be cooler.
  • The new GPU should be much faster, it's on a faster bus, and it has proprietary driver support (if required).
  • The SATA controller is more modern and should be much faster than the hard disk, the current controller is an older generation than the disk.
  • The RAM is much faster - two generations faster and there is four times as much of it.

Overall it should be faster, use less electricity, and be thermally cooler. It won't be as fast as my desktop, but it should be noticeably faster and my better half should be happy enough - especially as I shouldn't have to touch the data on the hard disk, which was only recently reinstalled.

Categories: LUG Community Blogs

Steve Kemp: lumail2 nears another release

Mon, 16/11/2015 - 18:35

I'm pleased with the way that Lumail2 development is proceeding, and it is reaching a point where there will be a second source-release.

I've made a lot of changes to the repository recently, and most of them boil down to moving code from the C++ side of the application, over to the Lua side.

This morning, for example, I updated the handing of index.limit to be entirely Lua based.

When you open a Maildir folder you see the list of messages it contains, as you would expect.

The notion of the index.limit is that you can limit the messages displayed, for example:

  • See all messages: Config:set( "index.limit", "all")
  • See only new/unread messages: Config:set( "index.limit", "new")
  • See only messages which arrived today: Config:set( "index.limit", "today")
  • See only messages which contain "Steve" in their formatted version: Config:set( "index.limit", "steve")

These are just examples that are present as defaults, but they give an idea of how things can work. I guess it isn't so different to Mutt's "limit" facilities - but thanks to the dynamic Lua nature of the application you can add your own with relative ease.

One of the biggest changes, recently, was the ability to display coloured text! That was always possible before, but a single line could only be one colour. Now colours can be mixed within a line, so this works as you might imagine:

Panel:append( "$[RED]This is red, $[GREEN]green, $[WHITE]white, and $[CYAN]cyan!" )

Other changes include a persistant cache of "stuff", which is Lua-based, the inclusion of at least one luarocks library to parse Date: headers, and a simple API for all our objects.

All good stuff. Perhaps time for a break in the next few weeks, but right now I think I'm making useful updates every other evening or so.

Categories: LUG Community Blogs

Adam Trickett: Bog Roll: Cold

Sat, 14/11/2015 - 14:58

I'm starting to get close to my target weight - only 3 kg to go according to BMI or a few centimetres according to height to waist ratio. Sadly for the past month I've not been able to get as much exercise as normal and I've hit another weight plateau.

Another strange phenomenon I'm experiencing is being cold. Normally even in mid winter I'm fine at work or home with short sleeved shirts and only on the coldest days do I need to wear a T-shirt under a regular shirt. In fact I've not worn or owned a proper vest for decades.

Last weekend I felt cold at home and put a jumper on. Something I wouldn't normally do in autumn. On Monday at work I felt cold but it was such a strange sensation that I didn't even recognise it. On Tuesday I went into M&S and bought a vest! Human fat doesn't provide the same level of insulation that blubber does for seals and whales, but it does provide some and more importantly on a diet the body down regulates thermogenesis to save energy. As I've been starving my self for 9 months to lose weight, it's hardly surprising that my body has decided that keeping warm isn't that important when I've shed over 21 kg.

Today isn't that cold - but it is pretty miserable. I've now got a vest, shirt, thin fleece and thick fleece gilet on. I even raised the temperature on the central heating thermostat up by 2°C...!

Categories: LUG Community Blogs

Andy Smith: Supermicro IPMI remote console on Ubuntu 14.04 through SSH tunnel

Fri, 13/11/2015 - 05:04

I normally don’t like using the web interface of Supermicro IPMI because it’s extremely clunky, unintuitive and uses Java in some places.

The other day however I needed to look at the console of a machine which had been left running Memtest86+. You can make Memtest86+ output to serial which is generally preferred for looking at it remotely, but this wasn’t run in that mode so was outputting nothing to the IPMI serial-over-LAN. I would have to use the Java remote console viewer.

As an added wrinkle, the IPMI network interfaces are on a network that I can’t access except through an SSH jump host.

So, I just gave it a go without doing anything special other than launching an SSH tunnel:

$ ssh me@jumphost -L127.0.0.1:1443:192.168.1.21:443 -N

This tunnels my localhost port 1443 to port 443 of 192.168.1.21 as available from the jump host. Local port 1443 used because binding low ports requires root privileges.

This allowed me to log in to the web interface of the IPMI at https://localhost:1443/, though it kept putting up a dialog which said I needed a newer JDK. Going to “Remote Control / Console Redirection” attempted to download a JNLP file and then said it failed to download.

This was with openjdk-7-jre and icedtea-7-plugin installed.

I decided maybe it would work better if I installed the Oracle Java 8 stuff (ugh). That was made easy by following these simple instructions. That’s an Ubuntu PPA which does everything for you, after you agree that you are a bad person who should feel badaccept the license.

This time things got a little further, but still failed saying it couldn’t download a JAR file. I noticed that it was trying to download the JAR from https://127.0.0.1:443/ even though my tunnel was on port 1443.

I eventually did get the remote console viewer to work but I’m not 100% convinced it was because I switched to Oracle Java.

So, basic networking issue here. Maybe it really needs port 443?

Okay, ran SSH as root so it could bind port 443. Got a bit further but now says “connection failed” with no diagnostics as to exactly what connection had failed. Still, gut instinct was that this was the remote console app having started but not having access to some port it needed.

Okay, ran SSH as a SOCKS proxy instead, set the SOCKS proxy in my browser. Same problem.

Did a search to see what ports the Supermicro remote console needs. Tried a new SSH command:

$ sudo ssh me@jumphost \ -L127.0.0.1:443:192.168.1.21:443 \ -L127.0.0.1:5900:192.168.1.21:5900 \ -L127.0.0.1:5901:192.168.1.21:5901 \ -L127.0.0.1:5120:192.168.1.21:5120 \ -L127.0.0.1:5123:192.168.1.21:5123 -N

Apart from a few popup dialogs complaining about “MalformedURLException: unknown protocol: socket” (wtf?), this now appears to work.

Categories: LUG Community Blogs

Debian Bits: New Debian Developers and Maintainers (September and October 2015)

Wed, 11/11/2015 - 21:35

The following contributors got their Debian Developer accounts in the last two months:

  • ChangZhuo Chen (czchen)
  • Eugene Zhukov (eugene)
  • Hugo Lefeuvre (hle)
  • Milan Kupcevic (milan)
  • Timo Weingärtner (tiwe)
  • Uwe Kleine-König (ukleinek)
  • Bernhard Schmidt (berni)
  • Stein Magnus Jodal (jodal)
  • Prach Pongpanich (prach)
  • Markus Koschany (apo)
  • Andy Simpkins (rattustrattus)

The following contributors were added as Debian Maintainers in the last two months:

  • Miguel A. Colón Vélez
  • Afif Elghraoui
  • Bastien Roucariès
  • Carsten Schoenert
  • Tomasz Nitecki
  • Christoph Ulrich Scholler
  • Mechtilde Stehmann
  • Alexandre Viau
  • Daniele Tricoli
  • Russell Sim
  • Benda Xu
  • Andrew Kelley
  • Ivan Udovichenko
  • Shih-Yuan Lee
  • Edward Betts
  • Punit Agrawal
  • Andreas Boll
  • Dave Hibberd
  • Alexandre Detiste
  • Marcio de Souza Oliveira
  • Andrew Ayer
  • Alf Gaida

Congratulations!

Categories: LUG Community Blogs

Andy Smith: Linux Software RAID and drive timeouts

Mon, 09/11/2015 - 09:06
All the RAIDs are breaking

I feel like I’ve been seeing a lot more threads on the linux-raid mailing list recently where people’s arrays have broken, they need help putting them back together (because they aren’t familiar with what to do in that situation), and it turns out that there’s nothing much wrong with the devices in question other than device timeouts.

When I say “a lot”, I mean, “more than I used to.”

I think the reason for the increase in failures may be that HDD vendors have been busy segregating their products into “desktop” and “RAID” editions in a somewhat arbitrary fashion, by removing features from the “desktop” editions in the drive firmware. One of the features that today’s consumer desktop drives tend to entirely lack is configurable error timeouts, also known as SCTERC, also known as TLER.

TL;DR

If you use redundant storage but may be using non-RAID drives, you absolutely must check them for configurable timeout support. If they don’t have it then you must increase your storage driver’s timeout to compensate, otherwise you risk data loss.

How do storage timeouts work, and when are they a factor?

When the operating system requests from or write to a particular drive sector and fails to do so, it keeps trying, and does nothing else while it is trying. An HDD that either does not have configurable timeouts or that has them disabled will keep doing this for quite a long time—minutes—and won’t be responding to any other command while it does that.

At some point Linux’s own timeouts will be exceeded and the Linux kernel will decide that there is something really wrong with the drive in question. It will try to reset it, and that will probably fail, because the drive will not be responding to the reset command. Linux will probably then reset the entire SATA or SCSI link and fail the IO request.

In a single drive situation (no RAID redundancy) it is probably a good thing that the drive tries really hard to get/set the data. If it really persists it just may work, and so there’s no data loss, and you are left under no illusion that your drive is really unwell and should be replaced soon.

In a multiple drive software RAID situation it’s a really bad thing. Linux MD will kick the drive out because as far as it is concerned it’s a drive that stopped responding to anything for several minutes. But why do you need to care? RAID is resilient, right? So a drive gets kicked out and added back again, it should be no problem.

Well, a lot of the time that’s true, but if you happen to hit another unreadable sector on some other drive while the array is degraded then you’ve got two drives kicked out, and so on. A bus / controller reset can also kick multiple drives out. It’s really easy to end up with an array that thinks it’s too damaged to function because of a relatively minor amount of unreadable sectors. RAID6 can’t help you here.

If you know what you’re doing you can still coerce such an array to assemble itself again and begin rebuilding, but if its component drives have long timeouts set then you may never be able to get it to rebuild fully!

What should happen in a RAID setup is that the drives give up quickly. In the case of a failed read, RAID just reads it from elsewhere and writes it back (causing a sector reallocation in the drive). The monthly scrub that Linux MD does catches these bad sectors before you have a bad time. You can monitor your reallocated sector count and know when a drive is going bad.

How to check/set drive timeouts

You can query the current timeout setting with smartctl like so:

# for drive in /sys/block/sd*; do drive="/dev/$(basename $drive)"; echo "$drive:"; smartctl -l scterc $drive; done

You hopefully end up with something like this:

/dev/sda: smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org   SCT Error Recovery Control: Read: 70 (7.0 seconds) Write: 70 (7.0 seconds)   /dev/sdb: smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org   SCT Error Recovery Control: Read: 70 (7.0 seconds) Write: 70 (7.0 seconds)

That’s a good result because it shows that configurable error timeouts (scterc) are supported, and the timeout is set to 70 all over. That’s in centiseconds, so it’s 7 seconds.

Consumer desktop drives from a few years ago might come back with something like this though:

SCT Error Recovery Control: Read: Disabled Write: Disabled

That would mean that the drive supports scterc, but does not enable it on power up. You will need to enable it yourself with smartctl again. Here’s how:

# smartctl -q errorsonly -l scterc,70,70 /dev/sda

That will be silent unless there is some error.

More modern consumer desktop drives probably won’t support scterc at all. They’ll look like this:

Warning: device does not support SCT Error Recovery Control command

Here you have no alternative but to tell Linux itself to expect this drive to take several minutes to recover from an error and please not aggressively reset it or its controller until at least that time has passed. 180 seconds has been found to be longer than any observed desktop drive will try for.

# echo 180 > /sys/block/sda/device/timeout I’ve got a mix of drives that support scterc, some that have it disabled, and some that don’t support it. What now?

It’s not difficult to come up with a script that leaves your drives set into their most optimal error timeout condition on each boot. Here’s a trivial example:

#!/bin/sh   for disk in `find /sys/block -maxdepth 1 -name 'sd*' | xargs -n 1 basename` do smartctl -q errorsonly -l scterc,70,70 /dev/$disk   if test $? -eq 4 then echo "/dev/$disk doesn't suppport scterc, setting timeout to 180s" '/o\' echo 180 > /sys/block/$disk/device/timeout else echo "/dev/$disk supports scterc " '\o/' fi done

If you call that from your system’s startup scripts (e.g. /etc/rc.local on Debian/Ubuntu) then it will try to set scterc to 7 seconds on every /dev/sd* block device. If it works, great. If it gets an error then it sets the device driver timeout to 180 seconds instead.

There are a couple of shortcomings with this approach, but I offer it here because it’s simple to understand.

It may do odd things if you have a /dev/sd* device that isn’t a real SATA/SCSI disk, for example if it’s iSCSI, or maybe some types of USB enclosure. If the drive is something that can be unplugged and plugged in again (like a USB or eSATA dock) then the drive may reset its scterc setting while unpowered and not get it back when re-plugged: the above script only runs at system boot time.

A more complete but more complex approach may be to get udev to do the work whenever it sees a new drive. That covers both boot time and any time one is plugged in. The smartctl project has had one of these scripts contributed. It looks very clever—for example it works out which devices are part of MD RAIDs—but I don’t use it yet myself as a simpler thing like the script above works for me.

What about hardware RAIDs?

A hardware RAID controller is going to set low timeouts on the drives itself, so as long as they support the feature you don’t have to worry about that.

If the support isn’t there in the drive then you may or may not be screwed there: chances are that the RAID controller is going to be smarter about how it handles slow requests and just ignore the drive for a while. If you are unlucky though you will end up in a position where some of your drives need the setting changed but you can’t directly address them with smartctl. Some brands e.g. 3ware/LSI do allow smartctl interaction through a control device.

When using hardware RAID it would be a good idea to only buy drives that support scterc.

What about ZFS?

I don’t know anything about ZFS and a quick look gives some conflicting advice:

Drives with scterc support don’t cost that much more, so I’d probably want to buy them and check it’s enabled if it were me.

What about btrfs?

As far as I can see btrfs does not disable drives, it leaves it until Linux does that, so you’re probably not at risk of losing data.

If your drives do support scterc though then you’re still best off making sure it’s set as otherwise things will crawl to a halt at the first sign of trouble.

What about NAS devices?

The thing about these is, they’re quite often just low-end hardware running Linux and doing Linux software RAID under the covers. With the disadvantage that you maybe can’t log in to them and change their timeout settings. This post claims that a few NAS vendors say they have their own timeouts and ignore scterc.

So which drives support SCTERC/TLER and how much more do they cost?

I’m not going to list any here because the list will become out of date too quickly. It’s just something to bear in mind, check for, and take action over.

Fart fart fart

Comments along the lines of “Always use hardware RAID” or “always use $filesystem” will be replaced with “fart fart fart,” so if that’s what you feel the need to say you should probably just do so on Twitter instead, where I will only have the choice to read them in my head as “fart fart fart.”

Categories: LUG Community Blogs

Steve Kemp: lumail2 approaches readiness

Thu, 05/11/2015 - 21:52

So the work on lumail2 is going well, and already I can see that it is a good idea. The main reason for (re)writing it is to unify a lot of the previous ad-hoc primitives (i.e. lua functions) and to try and push as much of the code into Lua, and out of C++, as possible. This work is already paying off with the introduction of new display-modes and simpler implementation.

View modes are an important part of lumail, because it is a modal mail-client. You're always in one mode:

  • maildir-mode
    • Shows you lists of Maildir-folders.
  • index-mode
    • Shows you lists of messages inside the maildir you selected.
  • message-mode
    • Shows you a single message.

This is nothing new, but there are two new modes:

  • attachment-mode
    • Shows you the attachments associated with the current message.
  • lua-mode
    • Shows you your configuration-settings and trivia.

Each of these modes draws lines of text on the screen, and those lines consist of things that Lua generated. So there is a direct mapping:

ModeLua Function maildirfunction maildir_view() indexfunction index_view() messagefunction message_view() luafunction lua_view()

With that in mind it is possible to write a function to scroll to the next line containing a pattern like so:

function find() local pattern = Screen:get_line( "Search for:" ) -- Get the global mode. local mode = Config:get("global.mode") -- Use that to get the lines we're currently displaying loadstring( "out = " .. mode .. "_view()" )() -- At this point "out" is a table containing lines that -- the current mode wishes to display. -- .. do searching here. end

Thus the whole thing is dynamic and mode-agnostic.

The other big change is pushing things to lua. So to reply to an email, populating the new message, appending your ~/.signature, is handled by Lua. As is forwarding a message, or composing a new mail.

The downside is that the configuration-file is now almost 1000 lines long, thanks to the many little function definitions, and key-binding setup.

At this rate the first test-release will be out at the weekend, but API documentation, and sample configuration file might make interesting reading until then.

Categories: LUG Community Blogs

Adam Trickett: Bog Roll: New Wombat

Tue, 03/11/2015 - 09:35

I realised that one of my desktop systems is now over a decade old, I bought it in 2005 and its starting to show it's age. The case and DVD drives are fine, the PSU and the hard disk have been upgraded mid-life, and there is nothing wrong with the display, keyboard and mouse. The problem is that the CPU is under-powered, there isn't enough RAM and the graphics subsystem is slow and no longer up to the job.

I've considered several option, but I think the least disruptive is a modern motherboard and faster current generation CPU. I can keep the case and most of the rest of the parts and just do a heart transplant.

Categories: LUG Community Blogs

Adam Trickett: Bog Roll: Blood pressure and weight

Sat, 31/10/2015 - 16:48

Since discovering I have elevated blood pressure and average but unhealthy levels of blood lipids at the start of this year I've made some small changes to my lifestyle. My diet was fundamentally sound but I have tweaked it a little and reduced the amount of it.

To date I've lost just over 21 kg at an average of 83 g per day, or in medieval units: 3 stones and 5 pounds at a rate of 3 ounces per day. It's important that the rate is slow so you don't stress your body and the weight loss should be sustainable as a result.

The last blood tests showed that my blood lipids had shifted drastically and are now very healthy, so my diet is worth sticking with. Yesterday I spoke to my GP, and after analysising a 5-day set of home blood pressure readings he's decided to stop the blood pressure medication.

I probably do have inherited high blood pressure, but my excess weight brought it on early and as long as I monitor it weekly we should be able to start medication again if it starts to rise up again.

My hybrid diet seems to have worked very well. To be honest I've only really tweaked what I was already eating, but the tweaks were worth the effort and I'll be sticking to the diet for ever now. I will be allowed a few extra calories per day - I do want to stop losing weight eventually!

The only real inconvenience has been having to replace most of my clothes, and as I've now shrunk down so much, even finding local shops that sell men's clothing that is even small enough to not look funny on me!

Categories: LUG Community Blogs

Steve Kemp: It begins - a new mail client, with lua scripting

Mon, 26/10/2015 - 22:01

Once upon a time I wrote a mail-client, which worked in the console directly via Maildir manipulation.

My mail client was written in C++, and used Lua for scripting unlike clients such as mutt, alpine, and similar alternatives which don't have complete scripting support.

I've pondered several times whether to restart this project, but I think it is the right thing to do.

The original lumail client has a rich API, but it is very ad-hoc and random. Functions were added where they seemed like a good idea, but with no real planning, and although there are grouped functions that operate similarly there isn't a lot of consistency. The implementation is clean in places, elegant in others, and horrid in yet more parts.

This time round everything is an object, accessible to Lua, with Lua, and for Lua. This time round all the drawing-magic is will be written in Lua.

So to display a list of Maildirs I create a bunch of objects, one for each Maildir, and then the Lua function Maildir.to_string is called. That function looks like this:

-- -- This method returns the text which is displayed when a maildir is -- to be show in maildir-mode. -- function Maildir.to_string(self) local total = self:total_messages() local unread = self:unread_messages() local path = self:path() local output = string.format( "[%05d / %05d] - %s", unread, total, path ); if ( unread > 0 ) then output = "$[RED]" .. output end if ( string.find( output, "Automated." ) ) then output = strip_colour( output ) output = "$[YELLOW]" .. output end return output end

The end result is something that looks like this:


[00001 / 00010 ] - Amazon.de
[00000 / 00023 ] - Automated.root

The formatting can thus be adjusted clearly, easily, and without hacking the core of the client. Providing I implement the apporpriate methods to the Maildir object.

It's still work in progress. You can view maildirs, view indexes, and view messages. You cannot reply, forward, or scroll properly. That said the hard part is done now, and I'm reasonably happy with it.

The sample configuration file is a bit verbose, but a good demonstration regardless.

See the code, if you wish, online here:

Categories: LUG Community Blogs