-
Section menu
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]
Section menu
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.
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.
# 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 |
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:
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
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
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.
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.
So I am again annoyed by wireless keyboard and mice, especially in an office environment, because:
