No ads? Contribute with BitCoins: 16hQid2ddoCwHDWN9NdSnARAfdXc2Shnoa
Aug 092018

Well that was a weird error; I recently discovered that ntpd had mysteriously stopped working; specifically it was not able to resolve NTP “pool” names :-

ntpd: error resolving pool Name or service not known (-2)

After some time spent blundering around down dead ends with the help of an appropriate search engine, I ended up resorting to strace. This is a tool most commonly used by developers but can be surprisingly useful for diagnosing system problems too.

As long as you can look past all the inscrutable output!

The strace tool runs a command and records every system call that the command calls together with the results. And of course most commands make zillions of system calls so you’re likely to end up with a huge output file.

To generate the output file, I ran the modern equivalent of ntpdate (ntpd -d) which tries to do the same thing using the actual NTP daemon. Usefully in this case because the command starts, configures itself (which is where the error occurs), and then exits (unlike the normal dæmon). It is important to redirect the output to have a file to trawl through later :-

strace ntpd -d > /var/tmp/ntpd.strace 2>&1

Once the output was generated, it was necessary to trawl through it to look for clues. The first thing was to search for “europe” (as I use as one of my NTP servers). The first occurrence was the error claiming that the name didn’t exist :-

write(2, "error resolving pool europe.pool"..., 73error resolving pool Name or service not known (-2)

Which was somewhat odd because you would expect the string “europe” to occur within an instructable attempt resolve the name. Yet it appears as though the error occurs without any attempt to resolve the name!

As a bit of a guess I searched for “resolv.conf” which revealed :-

stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=362, ...}) = 0
openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)

Apparently ntpd is unable to open the file due to a permissions problem!

Looking at my /etc/resolv.conf revealed an oddity dating back to when I tried configuring /etc/resolv.conf as a symbolic link to a file on a separate file system. The file itself was a symbolic link to /etc/resolv.conf.file.

For some reason ntpd didn’t like the symbolic link, which is a bit odd but changing it to an ordinary file fixed the problem.

Jul 302018

Alternatively, why does Windows use drive letters? Because if you are coming from an old unix background, drive letters are just as weird as the lack of them if you are coming from a Windows background.

I mean, why is Windows installed on drive C? What ever happened to drives A and B?

Technically Linux does have the equivalent of drive letters but they are rarely used directly (unless you’re weird like I am). For example I currently have an SD card plugged into my desktop system, and it has the path /dev/disk/by-label/EOS_DIGITAL (or /dev/sdo1).

Historically, Unix (which is loosely the predecessor of Linux) ran on large minicomputers where system administrators would decide what disks were “mounted” where.  The Linux equivalent of drive C is effectively “/” (root), and you can attach (or “mount”) disks at any point underneath that – for example /home.

This allowed people to use an old Unix machine without worrying where this disks were; and allowed system administrators to add and remove disks as and where they were needed. These days we are all system administrators as well as users – that little voice you hear from time to time saying things like “When would be a good time to update the operating system?” and “I must clean up those temporary files all over the place” are your inner system administrator speaking up.

And if you don’t hear that inner voice, cultivate it!

With device paths, Linux has the opportunity to create sensible friendly names for disks, but a historical accident has resulted in almost every kind of disk being identified as a SCSI disk – SATA disks (a normal hard disk), SAS disks (server hard disks), Fiber Channel disks (SAN hard disks), and even USB storage devices all use SCSI commands.

So nearly all Linux disks are identified as /dev/sd followed by a letter (a “drive letter” – we can’t get away from them) and a number indicating the partition. Fortunately there is also the relatively new /dev/disks directory that has slightly friendlier names for disk devices. If you are getting into low-level disk management, learn these directories; in particular if you are looking into enterprise disk management look at WWNs (each disk has a unique “world-wide-number”).

Now back to Windows. Windows is the descendent of DOS, which goes back to the time when PCs may not have had hard disks and by default would have booted off a floppy disk in drive A with a data disk in drive B. Later PCs came with hard disks which used drive C on the assumption that you would have one or two floppy drives.

Windows has been updated over the years and there is a great deal of sophistication under the surface, but it does act a bit conservatively when it comes to drive letters – A and B are by default reserved for floppy drives even though I haven’t seen one of those on an ordinary system for years. You can use A and B for other purposes such as mapping network drives – A makes a good drive for a NAS drive.

If we get away from the terminology of “drive letters” and “device paths” and instead refer to them as “storage device names”, both Linux and Windows have “storage device names” but Linux prefers to hide that level of detail.

Personally I prefer the Linux way, but whatever floats your boat.

Apr 012018

This is a continuation of an earlier post regarding ECC memory under Linux, and is how I added a little widget to display the current ECC memory status. Because I don’t really know lua, most of the work is carried out with a shell script that is run via cron on a frequent basis.

The shell script simply runs edac-util to obtain the number of correctable errors and uncorrectable errors, and formats the numbers in a way suitable for setting the text of a widget :-

# Use edac-util to report some numbers to display ...

correctables=$(edac-util --report=ce | awk '{print $NF}')
uncorrectables=$(edac-util --report=ue | awk '{print $NF}')

if [[ "$correctables" != "0" ]]
if [[ "$uncorrectables" != "0" ]]

echo "ECC: $correctables/$uncorrectables "

This is run with a crontab entry :-

*/7 * * * * /site/scripts/gen-ecc-wtext > /home/mike/lib/awesome/widget-texts/ecc-status

Once the file is being generated, the Awesome configuration can take effect :-

-- The following function does what it says and is used in a number of dumb widgets
-- to gather strings from shell scripts
function readfiletostring (filename)
  file =, "r")
  s =
  return s

eccstatus = wibox.widget.textbox()
eccstatus:set_markup(readfiletostring(homedir .. "/lib/awesome/widget-texts/ecc-status"))
eccstatustimer = timer({ timeout = 60 })
      eccstatus:set_markup(readfiletostring(homedir .. "/lib/awesome/widget-texts/ecc-status"))
layout = wibox.layout.fixed.horizontal, ... eccstatus, ...

There plenty of ways this could be improved – there’s nothing really that requires a separate shell script, but this works which is good enough for now.

Mar 092018

One of the things that annoys me about pagers such as lessmore, most, etc. is that they are dumb in the sense that they cannot detect the format of the text file they are displaying. For example, all of a sudden I find myself reading lots of markdown-formatted files, and I find myself using most to display it – never remembering that it is mdv I want.

As it happens, when I invoke a pager at the shell prompt, I typically use an alias (page or pg) to invoke a preferred pager, and by extending this functionality into a function I can start to approach what I want :-

function extension {
  printf "%s\n" ${argv/*\./}

function page {
 if [[ -z $argv ]]
   case $(extension $argv) in
       mdv -A $argv | $PAGER
       groff -m mandoc -Tutf8 $argv | $PAGER
       $PAGER $argv

Of course there are undoubtedly umpteen errors in that, and probably better ways to do it too. And it won’t work properly on its own ($PAGER hasn’t been set).
But it’s the start of something I can use to display all sorts of text files in a terminal window without having to remember all those commands. But as for ‘intelligent’, nope it’s not that – just a bit smarter than the average pager.

Feb 022018

On occasions, I have run into issues where mounting a filesystem from /etc/fstab fails on a reboot because it depends on something else happening first. The easiest example to recall is when mounting a conventional filesystem constructed from a ZPool block device – the block device isn’t ready until ZFS has finished starting which often occurs after the filesystem mounts are attempted.

The fix is dead simple; just add the option “_netdev” to the options field in /etc/fstab and the problem is sorted :-

/dev/zvol/pool1/vol-splunk      /opt/splunk     ext2    noatime,_netdev         0 2

Yes the reason I am using a block device is that Splunk doesn’t support being installed on a ZFS filesystem.

Sep 202017

By default, the Awesome window manager sets up 9 tags and uses a rather clever method for setting keyboard shortcuts for those tags.

And that is also one of the irritations of using Awesome because I have gotten into the habit of using more virtual screens (“tags”) than this. After a dumb way of increasing the number, I have come up with a rather improved method that can be used to replace the existing method in the Awesome rc.lua file :-

local taglist = { "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-", "=" }
-- The list of tags that I use.
 awful.tag( taglist, s, awful.layout.layouts[1])
for i = 1, #taglist do
  globalkeys = awful.util.table.join(globalkeys,
    awful.key({ modkey}, taglist[i],
                  function ()
                        local screen = awful.screen.focused()
                        local tag = screen.tags[i]
                        if tag then
                  {description = "view tag", group = "tag"}),
        awful.key({ modkey, "Control" }, taglist[i],
                  function ()
                      local screen = awful.screen.focused()
                      local tag = screen.tags[i]
                      if tag then
                  {description = "toggle tag", group = "tag"}),
        awful.key({ modkey, "Shift" }, taglist[i],
                  function ()
                      if client.focus then
                          local tag = client.focus.screen.tags[i]
                          if tag then
                  {description = "move focused client to tag", group = "tag"}),
        awful.key({ modkey, "Control", "Shift" }, taglist[i],
                  function ()
                      if client.focus then
                          local tag = client.focus.screen.tags[i]
                          if tag then
                  {description = "toggle focused client on tag", group = "tag"})

That’s three different parts of the code to change – a list of tags to use at the top of the file, a replacement somewhere in the middle, and a large chunk replacing existing code at the end of the keyboard configuration. I don’t claim this is better than the standard way, but it is handy for me.

The Window

Sep 092017

I recently switched from Ubuntu to Fedora Core for a variety of reasons :-

  • For a later version of fwupd as I had some vulnerable wireless mice to update.
  • To have a look at what Wayland was like (mostly invisible although oddball Window Managers still only talk to X).
  • To have a look at what it’s like after all these years; RedHat was one of the early distributions I ran.

All is reasonable except for one thing. The software updates.

What is this obsession with restarting to perform software updates? Is the relevant developer a refugee from Windows?

Now don’t get me wrong; a restart is the most effective simple way to ensure that outdated versions are not in use, but restarting every time you perform an update seems excessive.

  • If you need to update the kernel for security reasons, a restart is reasonable if you don’t have “live upgrades” but Fedora Core comes with a kernel that has that feature.
  • If you have a security update to a long-running process (such as Wayland or X), then you need to restart that process. In some cases you can restart a long-running process without notice; in others you will have to be disruptive, or ask someone to quit the long-running process.
  • If it isn’t a security update, you can simply wait until the user restarts the process.

Overall, the update process need not be as disruptive as Fedora Core makes it. It is of course not the end of the world to force a reboot, but it is hardly a very graceful process and some (including me) will find it annoying enough to avoid Fedora Core.

Post Interference

Aug 272017

Every so often, somebody (or organisation) proclaims that this year is the year of Linux on the desktop. Given the number of times this has occurred, you would have thought that the Cassandras of the Linux world would stop trying to predict it. In fact I am not entirely sure what it is supposed to be – everyone using Linux on the desktop, or just some? And if it is just some people, how many?

It is essentially nonsense – if you use Linux on the desktop, every year is the year of Linux on the desktop; and if you do not, it isn’t.

Assuming you are someone who has more than two brain cells to rub together and are prepared to do some learning, it is perfectly possible to run Linux on the desktop. You can do pretty much everything with Linux that you can do with Windows. In fact the one area that Linux is traditionally weak – upgrading firmware of third party devices (such as media players, wireless mice – is beginning to change with LVMS and fwupd.

To give an example, I was recently upgrading some Logitech wireless mice to eliminate a serious security flaw, and I tried with Windows, OSX, and finally Linux. Both the Windows and OSX methods failed, whereas the Linux method just worked.

In fact even if the Windows method had worked, it would have been a lot more complex. I had to download the Logitech software (admittedly this step would probably be unnecessary if I was used to using the wireless mouse under Windows), know that a firmware upgrade was necessary, download the firmware upgrade, and finally load it into the upgrade tool.

Under Linux? Assuming I had been using some gooey tool like GNOME Software, it would have notified me that an upgrade was available and after a request would have upgraded it for me. I (of course) chose to do it the geeky way from the command-line, but even so running :-

# fwupmgr refresh
# fwupmgr update

… is a great deal simpler than the Windows way. And that is before you consider that with Windows, you need to download a firmware update tool for every device whereas the Linux way it is just one tool.

Of course in practice, the Linux method only works for a handful of devices – of the innumerable Linux machines I run only one has available updates for the desktop computer’s firmware (the Dell at work), and of the peripheral (or not so peripheral) devices only a tiny handful can be upgraded today.

But it is not inconceivable that in the not too distant future, the sensible way to upgrade the firmware of various devices will be to install Linux, and let it do it for you. Particularly if device manufacturers realise that by adopting Linux as the firmware upgrade delivery method, they can save time and effort.

“But I know Windows” – actually you know Windows 7, or Windows XP, or Windows 10; each of which is very different from each other. And whilst Linux has even more variability at first glance, there is actually more commonality between different versions of Linux. Or in other words, the effort of learning Linux in the first place is rewarded by less of a need to completely re-educate yourself every time you upgrade.

This is not intended as encouragement for you to switch to Linux (although if you are involved in IT you should at least be familiar with Linux), but intended as a criticism of the concept of a year of the Linux desktop. It isn’t useful, and what is worse it leads to the false impression of failure – if everyone is not using Linux on the desktop, then Linux has failed.

Linux on the desktop has not failed because I use it on the desktop.

May 202017

I just love messing around with run-time languages that I know relatively little about (and if your sarcasm detector isn’t flashing red about now, take it out and give it a good talking to).

The problem detailed here is something that you are unlikely to encounter unless you get into weird stuff like running an odd-ball window manager, aren’t content with the version of said window manager distributed with your Linux distribution, and are used to re-compiling things from scratch.

It all started when I upgraded Ubuntu on my work machine (to Zesty Zapus). The window manager version was upgraded from 3.5 to 4.0, which broke on my configuration file (3.5); not a big problem I thought, as I had already upgraded my window manager at home to 4.1 and reconfigured the configuration file. I copied the updated configuration file from home into place.

And it failed. Apparently I use 4.1-isms within the file. As I was not happy about tinkering with the file to downgrade it (in a language I know relatively little about), I decided to re-compile Awesome 4.1 instead.

Which failed with a weird error :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: [string "return require('lgi.version')"]:1: module 'lgi.version' not found:
	no field package.preload['lgi.version']
	no file '/usr/local/share/lua/5.3/lgi/version.lua'
	no file '/usr/local/share/lua/5.2/lgi/version.lua'
	no file '/usr/local/share/lua/5.3/lgi/version/init.lua'
	no file '/usr/local/share/lua/5.2/lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version/init.lua'
	no file '/usr/share/lua/5.3/lgi/version.lua'
	no file '/usr/share/lua/5.3/lgi/version/init.lua'
	no file './lgi/version.lua'
	no file './lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi/'
	no file '/usr/lib/lua/5.3/lgi/'
	no file '/usr/local/lib/lua/5.3/'
	no file './lgi/'
	no file '/usr/local/lib/lua/5.3/'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/'
	no file '/usr/lib/lua/5.3/'
	no file '/usr/local/lib/lua/5.3/'
	no file './'

Which had me stumped for a while, and it turns out that DuckDuckGo didn’t have an obvious fix (one of the reasons for writing this).

Eventually I figured out that awesome was not finding the LGI module (I can be slow at times) which was odd because it was definitely installed. However it turns out that it was installed in /usr/share/lua/5.2/lgi. So despite having lua 5.3 installed, extra lua modules can only be seen if you have lua 5.2 installed?

The “fix” for this was to create an environment variable telling LUA to search for files in rather more places before starting Awesome :-

export LUA_PATH="/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.2/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/local/share/lua/5.2/?/init.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;/usr/share/lua/5.3/?.lua;/usr/share/lua/5.2/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/share/lua/5.2/?/init.lua;./?.lua;./?/init.lua"

This was created by running lua from the command line and running print(package.path) to display the default setting, and adding the 5.2 equivalent for many elements.

As to whether it works or not, well I cannot be sure (I’m not going into work on a weekend just to check if the window manager fires up), but Awesome itself seems happy with the result :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: 0.9.1

So it can find LGI, but whether it can do anything useful with it remains to be seen!

Feb 122017

A very long time ago, I used to collect spam in order to graph how much spam a single mail server was likely to get over time, and almost as long ago, I lost interest in maintaining it. As a consequence I still get a ton of spam every day and after a long period of procrastination I have been slowly raising defences against spam.

This particular recipe is not really a defence against spam – it verifies that the remote server is properly DNS registered with a reverse DNS registration – in other words that the IP address it is connecting from is registered. This is a requirement for all mail servers, and as it turns out, spammers don’t care for registering their servers in the DNS.

This ACL snippet goes into the ACL for checking the recipient or for checking the message :-

   message = Your mail server is not properly DNS registered
   log_message = BLOCKED: No rDNS
   condition = ${if eq{$host_lookup_failed} {1} {1}{0}}
   # Check rDNS and block if not registered

There are three items of interest :-

  1. The message is intended to be easily read by recipients to determine what the problem is. It turns out that many people do not read NDRs, but if we get the message right at least we are doing the right thing.
  2. The log_message is intended to make automating log parsing easier.
  3. Within the condition, the $host_lookup_failed variable indicates that the reverse DNS lookup returned NXDOMAIN and not that it timed out (which would be $host_lookup_deferred).

That’s all there is to this little piece of configuration.

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.