Computing notes 2019 part one

This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.

[file this blog page at: digg del.icio.us Technorati]

2019 June

190615 Sat: Keeping separate configuration data and templates

While discussing layers and flavours in configuration management (a bit densely) I forgot to mention an important aspect:

This allows for changing the structure of the lists of settings without changing the template content, only the initialization statements at the beginning where the global settings are assigned to local variables. This also because conceptually what settings are needed in a template file is a property of the template content, and that can be quite different from how to organize the global list of settings.

Consider for example some simplified setting for network configuration of a node called example:

node:
  "example":
    interfaces:
      - name: "eth0"
        auto: True
	method: "static"
        params:
	  netmask: 24
	  broadcast: "192.168.1.255"
	  gateway: "192.168.1.1"
	  address: "192.168.1.40"
    resolver:
      type: resolvconf
      options:
        resolvconf:
	  - "rotate"
	  - "attempts:2"
	  - "timeout:2"
	  - "ndots:1"
      search:
        - "example.org"
      nameservers:
        - "127.0.0.1"
        - "8.8.4.4"
        - "8.8.8.8"
Then this could be an example of template for /etc/network/interfaces:
{%-
  set interfaces = node.get(nodename).get("interfaces")
%}

auto lo
iface lo inet loopback
{%- for i in interfaces %}

  {%- if i.auto is not null and i.auto %}
auto {{i.name}}
  {%- endif %}
iface {{i.name}} inet {{i.method}}
{%-
  if i.method == "static"
    set p = i.params
    for k in keys(p)
      v = p.get(k)
%}
  {{k}} {{v}}
{%-
    endfor
  endif
endfor
%}
and this for /etc/resolv.conf:
{%-
  set resolver = node.get(nodename).get("resolver")
  # Any resolver should have a list of suffixes to search
  # and of nameservers to consult.
  set searchlist = resolver.get("search")
  set nameservers = resolver.get("nameservers")
  # These are options specific to 'resolv.conf'.
  set specific = resolver.get("resolvconf")
  set optionlist = specific.get("options")
%}
{%- if optionlist is not null %}

options {{optionlist | join(" "}}
{%- endif %}
{%- if searchlist is not null %}

search {{searchlist | join " "}}
{% endif %}

{%- for n in nameservers %}
nameserver {{n}}
{%- endfor %}

The point here is that there should be no complexity in the template text itself: just fixed text with simple variables interpolated.

2019 May

190529 Wed: Computer scientism and the SSSD service

Somewhat surprising news is that starting with RH EL 7.4 RedHat no longer support the PAM for Kerberos authentication (the most commonly used in many, many places) and only support it with the SSSD service provider.

Note: they do not support SSSD fully either, but only as part of IPA that is as configured by the scripts associated with it.

This is just a computer scientoid attitude, that of turning libraries into shared objects, shared objects into daemons, daemons into collections of microservices, often just because keeping it simple does not look on the CV of an architect.

But as to the details it is even worse: in effect SSSD is a replacement for both PAM and the NSS as it is something that accepts authN/authZ request or naming requests on the front-end, and has several pluggable back-ends, that have the following limitations:

But the funniest thing is that as to front ends only PAM and NSS are supported, so what is the point? In practice SSSD operates as a bloated, limited functionality PAM or SSSD pluggable module, yet it is meant in effect to replace PAM and SSSD.

190524 Tue: A simple test of ZFS record size and compression
# find linux-5.1.4 -type f | wc -l
63842
# find linux-5.1.4 -type f -size -16k | wc -l
51684

The space taken with ext4 is 943MiB:

Size compression recordsize
652MiB lz4 128KiB
1,008MiB zle 128KiB
1,120MiB off 128KiB
1,008MiB lz4 16KiB
1,387MiB zle 16KiB
1,474MiB off 16KiB
1,919MiB lz4 4KiB
1,920MiB zle 4KiB
1,930MiB off 4KiB

2019 April

190402 Tue: Speed of SSH ciphers and MACs in common cases

So I am dealing with two backup servers and most backups will happen over SSH. That's regrettable, because SSH is not that great (as it is not) a transport protocol, but it works almost everywhere, so we are stuck with it.

One of the problems is that encryption and checksumming overheads can slow it down considerably, and with default configuration much of the transfers I have seen were limited by that to around 40MB/s on a 1Gb/s line capable of 100-110MB/s.

Various people have been looking at which mix of cipher and MAC algorithm gives the best speed and I was impressed by a note that MAC algorithm speed also matters and some comprehensive comparisons, so I decided to do my own confirmatory quick tests in my environment where there is a mix of older and newer hardware, and my results are faily clear:

Overall I have 3 different lists for very recent, recent and legacy distributions:

Ubuntu LTS 18
  Ciphers	aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-ctr,aes128-cbc,aes256-gcm@openssh.com,aes192-ctr,aes256-ctr,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
  MACs		umac-64-etm@openssh.com,umac-64@openssh.com,hmac-md5-96-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96,hmac-sha1-96,umac-128-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256-etm@openssh.com,hmac-sha2-256,hmac-sha2-512-etm@openssh.com,hmac-sha2-512
Ubuntu LTS 16 and 14
  Ciphers	aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-ctr,arcfour128,aes128-cbc,aes256-gcm@openssh.com,aes192-ctr,aes256-ctr,arcfour256,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour,rijndael-cbc@lysator.liu.se
  MACs		umac-64-etm@openssh.com,umac-64@openssh.com,hmac-md5-96-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96,hmac-sha1-96,umac-128-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256-etm@openssh.com,hmac-sha2-256,hmac-sha2-512-etm@openssh.com,hmac-sha2-512
Legacy
  Ciphers	aes128-ctr,arcfour128,aes128-cbc,aes192-ctr,aes256-ctr,arcfour256,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour,rijndael-cbc@lysator.liu.se
  MACs		umac-64@openssh.com,hmac-md5-96,hmac-sha1-96,hmac-md5,hmac-sha1

I also tried the same transfer from and to localhost from and to a tmpfs filetree wholly resident in RAM, on a recent CPU with AES acceleration, and the fastest rate I got was 230MB/s with aes128-ctr (and 180MB/s with arcfour128. That is rather less than a 10Gb/s network link can do, and rather slower than what IPsec with AES acceleration can do, which is disappointing; probably going faster would require OpenSSH to run fully multithreaded.

2019 March

190331 Sun: Impressions of 27in 3840×2160 monitor KA270HK

Some time ago I found online a low price end of line offer for an Acer KA270HK as it was about to be replaced with a newer model, and I bought it.

Part of the reason was that it is a 27in monitor, and my previous 32in Acer B326HUL was too big for my small home desk (fairly good for my bigger work desk, but still a bit big), and the 24in Dell U2412M I was using at home felt a bit too small.

Part of the the reason was that it has a 4k (QHD) display, with a 3840×2160 160DPI resolution, while the B326HUL is 2560×1440 and the U2412M is 1920×1200 both with a 100DPI resolution.

The monitor overall is very good: it is pretty decently built, the IPS panel has excellent image quality (almost equal to that of the amazing U2412M), and even if it has a low end unadjustable stand, I have a nice monitor arm and the monitor has a compatible VESA mount and is (crucially) light enough to be mounted on it (the 32in Acer was way too heavy).

As to the specific size I find that 27in is the ideal compromise between 32in and 24in: it is way more comfortable than 24in, and not as huge as 32in, and at 27in it is still light enough that can be mounted on an ordinary monitor arm. When using the 32in monitor I find that I tend not to use, except perhaps to hold unused windows, a slice of the left and right ends of its surface, and that the 24in one make me overlap windows too much, while the 27in it both fully used and does not require me too much overlapping.

Also as mentioned in another blog a 160DPI display is a definite improvement on a 100DPI one. At the distance I which I put monitors pixels are already difficult to discern with a 100DPI display, but are really invisible on a 160DPI one, where the adjusted DPI are around 200.

It also turns out that most recent GUI libraries handle well HiDPI displays, that is they use scalable fonts, scalable icons, scalable geometries. I have used GNOME 3, KDE 5, XFCE 4 and they all scale fairly well, and the few things that don't scale are still somewhat readable at what is roughly half-size.

As to media, looking at photos from recent digital cameras and cellphones in something more like their native resolution is a definite improvement, and while most movies are distributed in rather smaller resolution, the enlargement algorithms in most players work pretty well. Games are usually inherently scalable, except for textures, but they work fairly well for me in a window at 3200×1800 pixels. Very cool to look at, and while the more recent games demand a powerful and costly GPU (which I don't have), older games don't, and even recent games benefit from the resolution being so high that anti-aliasing, which is usually very expensive, is not necessary or can be dialed down a lot.

So far these impressions look rather positive, so what are the downsides? Well, really only one and relatively minor: bandwidth. To refresh a 3840×2160 32 bit image at 60Hz takes a lot of bandwidth and there are several case where it is not supported:

But all this is relatively minor as currently the bandwidth limitation is rather less of an issue for me, as I have moved some time ago to using mostly by relatively recent desktop instead of my older laptop as my main home system.

190323 Sat: Wireless keyboard and mice: just say no

So I am again annoyed by wireless keyboard and mice, especially in an office environment, because: