One of the things still needing migrating is the NTP server stats which obviously uses rrdtool. Because I want to keep the history I migrated the datasets with:

/usr/local/rrdtool/bin/rrdtool dump ntpvals-stardate.cs.uu.nl.rrd \
| ssh newhost /usr/bin/rrdtool restore -f - ntpvals-stardate.cs.uu.nl.rrd

And then create a graph of the plloffset for example using:

/usr/bin/rrdtool graph /tmp/plloffset-stardate.cs.uu.nl-24hours.png \
--title "stardate.cs.uu.nl pll offset (last 24 hours)" --imginfo \
'<img src="tmpgraphs/%s" WIDTH="%lu" HEIGHT="%lu" alt="Graph">' \
--start -24hours --end now --vertical-label="Seconds" --color BACK#0000FF \
--color CANVAS#c0e5ff --color FONT#ffffff --color GRID#ffffff \
--color MGRID#ffffff --alt-autoscale --imgformat PNG --lazy \
DEF:offset=ntpvals-stardate.cs.uu.nl.rrd:plloffset:AVERAGE \
CDEF:wipeout=offset,UN,INF,UNKN,IF CDEF:wipeoutn=wipeout,-1,* \
LINE1:offset#000000:"Offset\:" \
GPRINT:offset:LAST:"Current\:%.3lf%s" \
GPRINT:offset:MIN:"Min\:%.3lf%S" \
GPRINT:offset:MAX:"Max\:%.3lf%S" \
GPRINT:offset:AVERAGE:"Average\:%.3lf%S" \
AREA:wipeout#e0e0e0 AREA:wipeoutn#e0e0e0

But on the old server this takes 0.026 seconds, on the new server 3 minutes and 47.46 seconds. No idea what is happening, strace shows nothing strange and rrdtool uses 1 cpu at 100% all that time.

My amateur club Veron A08 call PI4UTR has a really good clubstation with multiple nice antennas. In an environment with a lot less interference than I have at home.

Last Tuesday I used the clubstation to make a few connections and got some nice calls in the log, adding two new countries. VP8LP on the Falkland Islands and CE2ML in Chili.

I use the logcheck package to monitor for unexpected log entries. Since upgrading to the new homeserver conway I noticed DNSSEC failures coming back regularly, even at weird times of the night while the domain names seemed related to services we sometimes interact with during the day. To search deeper I enabled query logging on DNS (with a short retention period) in order to find the source.

Eventually I found it: the DNSSEC failures came at the time the mail from logcheck was delivered, because it mentioned domain names that cause a DNSSEC failure. So the way to 'fix' this problem and avoid similar other problems was to whitelist logcheck mail.

Update 2018-10-05: That only helps when enabling the Mail::SpamAssassin::Plugin::Shortcircuit plugin and enabling the USER_IN_WHITELIST shortcircuit.

Update 2018-10-07: Even with whitelist and shortcircuit I still see queries for domain names in the logcheck mails. Call to spamassassin is now changed...

Now, once again...this time with FEEwing

This morning I was looking on shodan for open remote desktop servers in the work network since RDP was mentioned as an attack vector in the latest GANDCRAP ransomware.

Searching for '3389' on shodan found something completely different: an open industrial control system (ICS) for tankstation gauges.

IN-TANK VOORRAAD        

TANK PRODUCT             VOLUME TC VOLUME   VULVOL   HOOGTE    WATER     TEMP
  1  UL 98                 9757      9693    10283    939.2      0.0    20.09
  2  EURO                 2...

According to The Internet of Gas Station Tank Gauges -- Take #2 - Rapid7 this was already a reported issue in January 2015 and according to their research it may be possible to do bad things with this access.

The above is from a gas station I can find on google maps.

Oh I found the way to search for open remote desktop servers on shodan: port:3389.

So for months and months I had hardware ready for the new homeserver, I was testing bits and pieces in the new environment and I still did not get around to making the big bang. Part of the time the new system was running and using electricity.

And a few weeks ago I had time for the big bang and forgot to mention it!

So one free day I just did the last sync of homedirectories and started migrating all services in a big bang. No more but, if, when, is it done yet. It's a homeserver, not a complete operational datacenter. Although with everything running it sometimes does look that way!

The new setup, more completely documented at Building - and maintaining home server conway 2017 is now running almost all tasks. The main migration was homedirectories, mail, news, webservers. Things are now split over several virtual machines and the base virtual machine running kvm virtual machines is as minimal as possible.

One thing I just noticed is that the new virtual machine with pppoe kernel mode drivers and updated software is doing great: the bigger MTU is working by default and kernel mode pppoe does not show up as using CPU when a 50 mbit download is active. I looked at CPU usage with htop and at the network traffic with iptraf and the result was that iptraf was using the most cpu.

There are still some things left to migrate, including a few public websites that currently give 50x errors. But I will find the time eventually.

In Maart 2018 begonnen er werkzaamheden aan de fietspaden rond het Eykmanplein. Er stond toen een bordje bij het fietspad over 'enige verkeershinder'. Ondertussen zijn we zes maanden verder en is er nog steeds behoorlijk veel verkeershinder voor mij als fietser.

Vandaag was een nieuw record, door het tegelijk uitvoeren van twee projecten moet ik nu met de fiets 3 keer de Kardinaal de Jongweg oversteken met iedere keer wachttijden voor verkeerslichten en een paar extra haakse bochten en krappe plekken.

Mijn normale route is dat ik uit de Professor J.W. Dieperinklaan kom, rechtsaf het fietspad langs de Eykmanlaan neem, dan op het Eykmanplein eerst de Kardinaal de Jongweg en daarna de Blauwkapelseweg oversteek, vervolgens over de Van Esveldstraat fiets en dan de route vervolg met het fietspad langs de Kardinaal de Jongweg.

Ingetekend op een OpenStreetMap kaartje: mijn normale route rond het Eykmanplein. In deze route rij ik op fietspaden aan de rechterkant van de weg en heb ik geen scherpe bochten en lastige opstoppingen.

De werkzaamheden van het project fietsroute Overvecht-Utrecht Science Park zijn dus in Maart 2018 begonnen. Dat begon aan de Pieter Nieuwlandstraat waardoor het niet meer mogelijk was normaal om de rotonde te rijden. Dan maar de Eykmanlaan oversteken na een scherpe hoek en uiteindelijk pas bij de Jan van Galenstraat oversteken.

Ingetekend op hetzelfde kaartje: de eerste omleiding rond het Eykmanplein. Met rood aangegeven waar ik blokkades tegenkwam.

De Van Esveldstraat is maar kort weer open geweest nadat ik weer langs die kant om het Eykmanplein kon, daarna ging alles daar weer open.

Vandaag kwam er nog bij dat de Eykmanlaan opengebroken werd vanwege het project Opnieuw inrichten Eykmanlaan.

In de planning van dit project is ingetekend dat er oversteekmogelijkheden blijven voor fietsers en voetgangers op de Eykmanlaan. Alleen waren die vandaag niet uitgevoerd, er staat nu een hek langs de zijkant van de Eykmanlaan om dat oversteken compleet onmogelijk te maken.

De fietsroute zoals deze nu uitkomt ingetekend op het kaartje: de dubbele omleiding rond het Eykmanplein. Met ook in rood de blokkades.

I still like running sendmail on my own systems. But sendmail evolves with time and my configuration does improve slightly sometimes, such as on the introduction of authenticated smtp with secondary passwords.

After the recent upgrades to the home server there is a new mail server with some other new details and suddenly other systems at home could not relay. A bit of searching found Best practice: sendmail and SMTP auth with the right flags for the DAEMON_OPTIONS to only offer authentication on port 587 (submission).

I noticed the local systems tried relaying via port 587 so I changed this to port 25 where IP-based relaying is allowed. No idea why I set this up to use the port 587 when I set it up previously.

And yes, I checked it, I started with sendmail in 1993, so 25 years of sendmail on port 25. I did start with writing my own sendmail.cf rules but I switched to .mc based configurations.

The work laptop is now "upgraded" to Windows 10. I wasn't sure about it as I saw Windows 7 as less annoying but it's the corporate choice.

And after I changed the password for my eduroam wifi-account it just gives an error and does not connect to the wireless network. The obvious choice to show the option to enter a new password does not pop up (unlike Android which came with that suggestion right away). Even the "network troubleshooter" doesn't come with the source of the connection problem let alone the obvious solution.

The Windows 10 "solution" is to just forget the network and discover it again. I'm glad this isn't a network where I need special options and a certificate to log in.

With some systems constantly running screen and others not I started to get confused. Solution: change the visual indications in the prompt inside screen.

I decided to just change the username color in PS1 when I'm in screen. So now:

PS1='${STY:+\[\e[1;36m\]}\u${STY:+\[\e[0m\]}@\h:\w\$ '

In bash, ${STY:+..} gives output when shell variable STY is set. So I add the color set/unset commands to the prompt when STY, a typical screen variable is set. The result is dark cyan, a color that works (for me) on my normal light-grey background xterm/putty sessions.

Oh, and for root things are different:

PS1='\[\e[1;91m\]\u@\h\[\e[0m\]:\w\$ '

Which gives a light red user@hostname.

In the above \e causes an escape to be printed. Wrapping parts of the prompt between \[ and \] causes bash to ignore those for counting the length of the prompt so it doesn't get confused on redrawing the prompt when editing the commandline.

Samples of colours and other formatting at FLOZz' MISC » bash:tip_colors_and_formatting.