neitzels irrelevant irregular intarweb notes

I spent another night with Robert Nordier's UNIX V7 port to the x86 architecture (http://www.nordier.com/v7x86/index.html).

The first attempt had been a few months before on a real 32-bit netbook with a real spinning harddisk and a primary partition. The V7 system booted from the CDROM on a USB-attached drive just fine. But since the USB drive is not an ATAPI drive as assumed by the V7/x86, the installation process failed. (It would have been so nice to have the V7 right next to the Solaris10 on the same disk...)

This time I tried an installation in a proxmox VM, the ISO image being attached as a virtual IDE/ATAPI drive. (I had fired up ron running a proxmox installation just yesterday to check its version; I was pleasently surprised that I was at the same major release as a customer whom I need to support now.)

The V7/x86 installation ISO allows to escape into a shell in order to partition the target disk with a ptdisk utility. I then ran into the issue which I eventually found documented in http://www.nordier.com/v7x86/files/ISSUES.

I was able to extract the missing /boot/mbr from the CDROM and run the ptdisk using it. This allowed the installation to run. However, the resulting MBR wouldn't boot the system from the (virtual) disk afterwards.

I guess it's a C/H/S geometry issue. I toyed around a bit before giving up. My next attempt would be to boot another OS on this VM to fdisk the disk, then try again with the V7/x86 install (as advised in the mentioned ISSUES page).

Summary:

Lots of dd and od today... and also echo * because: the v7 ls is strictly -1.

A small survey how different marshlabs hosts, all running systemd, get their network interface configured. As it turns out there is quite variety.

ron

A ProxmoxVE 4.4 host, running Debian-8. The network configuration still resides in /etc/network/interfaces for use with ifup/ifdown and a sysV init script:

$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto vmbr0
iface vmbr0 inet static
    address 217.13.64.160
    netmask 255.255.255.192
    gateway 217.13.64.161
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0

$ systemctl status network\*
* networking.service - LSB: Raise network interfaces.
   Loaded: loaded (/etc/init.d/networking)
  Drop-In: /run/systemd/generator/networking.service.d
       `-50-insserv.conf-$network.conf
    /lib/systemd/system/networking.service.d
       `-network-pre.conf
   Active: active (exited) since Sat 2018-06-23 16:16:40 CEST; 4 days ago
$

ry

A Raspian system, also Debian-8.0-based. Again, /etc/network/interfaces and networking.service auto-derived from the init.d script are used. This time, though, interfaces says:

iface eth0 inet manual

The configuration is completed by

$ systemctl status dhc\*
* dhcpcd.service - dhcpcd on all interfaces
   Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled)
   Active: active (running) since Sun 2018-04-29 13:17:06 CEST; 1 months 28 days ago
 Main PID: 424 (dhcpcd)
   CGroup: /system.slice/dhcpcd.service
       `-424 /sbin/dhcpcd -q -b

foo

An LXC container within ron, running archlinux:

[root@foo neitzel]# systemctl status netwo\*
* network.target - Network
   Loaded: loaded (/usr/lib/systemd/system/network.target; static; vendor prese>
   Active: active since Wed 2018-06-27 16:16:28 CEST; 1h 11min ago
     Docs: man:systemd.special(7)
       https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

Jun 27 16:16:28 foo systemd[1]: Reached target Network.

[root@foo neitzel]# locate \*.network
/etc/systemd/network/eth0.network
/usr/lib/systemd/network/80-container-host0.network
/usr/lib/systemd/network/80-container-ve.network
/usr/lib/systemd/network/80-container-vz.network

[root@foo neitzel]# cat /etc/systemd/network/eth0.network
[Match]
Name = eth0

[Network]
Description = Interface eth0 autoconfigured by PVE
Address = auto
DHCP = v4

[root@foo neitzel]# systemctl status dhc*
[root@foo neitzel]#

Summary: foo is the only system here using systemd-networkd.

Yesterday, I wondered why a ubuntu-16 system wouldn't lose its DHCP address after a change from dhcp to static in /etc/network/interfaces.

TIL: there was also /etc/network/interfaces.d/50-cloud-init.conf, still providing the old specs for both the loopback and ethernet interfaces. Fixed via rm.

I am getting too old for this crap. In particular, I was too old to notice the .d subdirectory. Let's blame the color-ls.

The last NetBSD 8.0 RC1 build from May 12th on eddie was getting a bit stale. So I picked up the latest CVS changes in the night from Saturday to Sunday and started the build Sunday around 2pm. Around 4pm, with the build well on its way, I got informed via IRC that 8.0_RC2 had just been tagged... story of my life.

Nevertheless, I finished the builds tonight and did all the install steps. Another CVS update afterwards showed that the additional changes for RC2 are very minor, so I am effectively "there".

All in all: smooth sailing, as usally.

arto.marshlabs.gaertner.de is my first installation of the Arch Linux distribution. It lives in a disk partion of my fourth(!) Atom-N270 netbook. This one also hosts carlton (Solaris10) and philip (Debian-9). Because the Arch project dumped the i368 architecture last year, arto is actually an install hinged on the archlinux32.org fork.

I like Arch's combination of traditional BSD values (a lean base installation and the assumption that admins are capable of reading documentation) with modern linux technologies (systemd etc.).

After the install in March 2018 and some initial update, today was only my third or fourth boot of arto. So far, I had configured the network only manually and ad-hoc. The next step now is to find the proper place to nail some sort of network configuration down.

A few days ago I had already done some research. Arch systems come out of the box with the options to do the network setup either with plain systemd-networkd or the Arch-specific netctl. The latter is apparently a tool to manage different network setups and switch between them, for example when travelling around with a laptop. Today's original plan was to look more into this, and at least to get into the basics of systemd-networkd.

I didn't come even close to tackle anything of this today, though. What led me astray: my login.

I did not want to work directly on the netbook console today for various reasons:

1. The netbook's keyboard layout is a bit awkward around the right shift key.
2. The fan is activated every 5-10 minutes. It is just a short one-minute run but a bit noisy and irritating.
3. I had other machines to tend to, too, all of them already present in my desktop screen assembly.
4. I definitely needed a screen with a graphical web browser, not the least for reading the Arch Linux documentation.

So I wanted to log into arto from remote but the arch-linux base installation comes without sshd. It does have telnetd and rlogind on board, though. I manually started the latter, logged into the system, and the rest of the day was spent on just two topics:

1. pacman(8): How to enquire about local and remote packages, check for packages, and add them. Find the files associated with a package and vice versa.
2. systemctl(1) etc.: How to properly enable a service such as rlogind.

In particular, I learned that systemd's socket units replace the traditional inetd services.

Some surprises today: connecting to rlogind turned out to be difficult for various reasons. Out of the box, rlogind will listen on IPv4 and IPv6 (good), but the daemon will fail on DNS-verifting the IPv4 client address because it will be presented as a compatible v6 address (i.e. as ::ffff:1.2.3.4). Also, when run as systemd-service, the PAM modules wouldn't authorize my logins.

This still has to be analyzed in more detail.

Meanwhile, sshd is already installed and should be running the next time I boot arto. Perhaps, just perhaps, I'll get around to do the address configuration then.

There are three kinds of lies: lies, damned lies, and cups(1).

Anticipated for weeks, with champagne in the fridge, but nevertheless missed yesterday:

neitzel 539 > uptime
  6:10pm  up 1499 days,  3:13,  5 users,  load average: 0.00, 0.00, 0.00
neitzel 540 > uptime
  9:08pm  up 1501 days,  6:11,  5 users,  load average: 0.00, 0.00, 0.00
neitzel 541 > uname -a
ULTRIX ips 4.4 0 RISC

Damn, damn, damn. Next round uptime dates would be:

• 1536 (11000000000) days on July, 23rd,
• 5 years on 2019-05-09, and of course
• 2000 days on October, 30th, 2019.

Go for it, little ips!

Ten days ago, I made my first REST queries using the shell.

Two days later, I tried the same queries with J. This turned out to be quite easy because two addons do all the work:

   require 'web/gethttp convert/json'
   j =. gethttp 'https://atlas.ripe.net/api/v2/probes/2871'

   _60 ]\ j
{"prefix_v4":"217.13.64.0/20","status":{"since":"2018-06-13T
04:35:32Z","id":1,"name":"Connected"},"prefix_v6":"2a00:1030
::/32","description":"GDS Marshlabs","last_connected":152912
2097,"tags":[{"name":"DSL","slug":"dsl"},{"name":"Home","slu
g":"home"},{"name":"No NAT","slug":"no-nat"},{"name":"IPv6 T
unnel","slug":"ipv6-tunnel"},{"name":"dual-stack","slug":"du
al-stack"},{"name":"IPv4","slug":"ipv4"},{"name":"IPv6","slu
g":"ipv6"},{"name":"system: V2","slug":"system-v2"},{"name":
"system: Resolver Mangles Case","slug":"system-resolver-mang
les-case"},{"name":"system: IPv4 Works","slug":"system-ipv4-
works"},{"name":"system: IPv6 Works","slug":"system-ipv6-wor
ks"},{"name":"Native IPv4","slug":"native-ipv4"},{"name":"sy
stem: IPv4 Capable","slug":"system-ipv4-capable"},{"name":"s
ystem: IPv6 Capable","slug":"system-ipv6-capable"},{"name":"
system: IPv6 Stable 1d","slug":"system-ipv6-stable-1d"},{"na
me":"system: IPv4 Stable 1d","slug":"system-ipv4-stable-1d"}
],"geometry":{"type":"Point","coordinates":[10.5215,52.2675]
},"type":"Probe","address_v6":"2a00:1030:100:0:220:4aff:fee0
:2212","address_v4":"217.13.64.149","total_uptime":190721773
,"country_code":"DE","is_public":true,"id":2781,"asn_v4":249
56,"asn_v6":24956,"status_since":1528864532,"first_connected
":1333468450,"is_anchor":false}                             

   _ 3 {. dec_json j
┌──────────────┬───────────────────────────────────┬──────────────┐
│prefix_v4     │status                             │prefix_v6     │
├──────────────┼───────────────────────────────────┼──────────────┤
│217.13.64.0/20│┌────────────────────┬──┬─────────┐│2a00:1030::/32│
│              ││since               │id│name     ││              │
│              │├────────────────────┼──┼─────────┤│              │
│              ││2018-06-13T04:35:32Z│1 │Connected││              │
│              │└────────────────────┴──┴─────────┘│              │
└──────────────┴───────────────────────────────────┴──────────────┘

So the json decoder turns syntactical markup into equivalent nested boxed data in the J world.

The J primitives dealing with such nested boxes are

1. L. Level Of
2. L: Level At
3. {:: Map/Fetch
4. S: Spread

Time to dig deeper into these. I spent a few hours until I really understood why, for example,

   |.  L:1  ] _ 3 {. dec_json j
┌──────────────┬───────────────────────────────────┬──────────────┐
│4v_xiferp     │sutats                             │6v_xiferp     │
├──────────────┼───────────────────────────────────┼──────────────┤
│02/0.46.31.712│┌────────────────────┬──┬─────────┐│23/::0301:00a2│
│              ││2018-06-13T04:35:32Z│1 │Connected││              │
│              │├────────────────────┼──┼─────────┤│              │
│              ││since               │id│name     ││              │
│              │└────────────────────┴──┴─────────┘│              │
└──────────────┴───────────────────────────────────┴──────────────┘

As of now, I am missing the flexibility of the { From selectors with the very rigid {:: Fetch paths. Some blend would be nice.

Also, I am still marvelling at possibilities of dyadic L: applications:

   a
┌───┬──────────────────┐
│1 2│┌────┬───────────┐│
│   ││abcd│0 1 2 3 4 5││
│   │└────┴───────────┘│
└───┴──────────────────┘
   c
┌─────┬─────┐
│┌───┐│┌───┐│
││ABC│││DEF││
│└───┘│└───┘│
└─────┴─────┘

   a ;L:0 c
┌───────────┬──────────────────────────────┐
│┌─────────┐│┌──────────┬─────────────────┐│
││┌───┬───┐│││┌────┬───┐│┌───────────┬───┐││
│││1 2│ABC│││││abcd│DEF│││0 1 2 3 4 5│DEF│││
││└───┴───┘│││└────┴───┘│└───────────┴───┘││
│└─────────┘│└──────────┴─────────────────┘│
└───────────┴──────────────────────────────┘
   a ;L:1 c
┌─────────┬────────────────────────┐
│┌───┬───┐│┌──────────────────┬───┐│
││1 2│ABC│││┌────┬───────────┐│DEF││
│└───┴───┘│││abcd│0 1 2 3 4 5││   ││
│         ││└────┴───────────┘│   ││
│         │└──────────────────┴───┘│
└─────────┴────────────────────────┘

Maybe I'll do less extra boxing for enabling each as in

   (;:'foo bar')  ,each  <'extraboxhere'
┌───────────────┬───────────────┐
│fooextraboxhere│barextraboxhere│
└───────────────┴───────────────┘

and employ L: instead in the future:

   (;:'foo bar')  ,L:0  'noextraboxhere'
┌─────────────────┬─────────────────┐
│foonoextraboxhere│barnoextraboxhere│
└─────────────────┴─────────────────┘

We'll see.

A small Y2K fix for w(1) on ips.marshlabs.gaertner.de (ULTRIX 4.4).

Before:

ROOT@ips 110 > w
  3:00am  up 1498 days, 12:03,  5 users,  load average: 0.11, 0.01, 0.00
User     tty from           login@  idle   JCPU   PCPU  what
neitzel  p1 alexis:S.4     19Oct115  3:38 506:49     17  -usr/bin/tcsh
neitzel  p2 alexis:S.2     15Aug115  3:38   1:53      6  -usr/bin/tcsh
neitzel  p4 alexis:S.3     16Aug115  3:38   1:35      6  -usr/bin/tcsh
neitzel  p5 alexis:S.1     25Oct116  3:38                -
neitzel  p6 alexis:S.5     13Jun117                      -

After:

ROOT@ips 111 > \./w
  3:00am  up 1498 days, 12:03,  5 users,  load average: 0.09, 0.00, 0.00
User     tty from           login@  idle   JCPU   PCPU  what
neitzel  p1 alexis:S.4     19Oct15  3:38 506:49     17  -usr/bin/tcsh
neitzel  p2 alexis:S.2     15Aug15  3:38   1:53      6  -usr/bin/tcsh
neitzel  p4 alexis:S.3     16Aug15  3:38   1:35      6  -usr/bin/tcsh
neitzel  p5 alexis:S.1     25Oct16  3:38                -
neitzel  p6 alexis:S.5     13Jun17                      -

cp w /usr/usb/w -- done, Natasha. (And yes, that's just 36 hours to go for 1K5 days uptime.)

This is the first and only blog entry today with an honest date. The other two were made afer-the-fact for the last week.

I need to do this often. (Just maybe I'll fill in a few snippets for the huge last 2-year gap.) So as a personal reminder, this is how to do it:

nb --var TIMESTAMP --set-var 2018-06-06T16:00:00 add entry

(The time without a zone spec is used as local time.) The documented way is:

nb --var TIMESTAMP --set-var "2018-06-06 16:00:00" add entry

but this does not work; the space is just wrong.

Also possible: specifying

TIMESTAMP: 2018-06-06T16:00:00

instead of(!) a DATE: in the new header.

Stating the intended date in the DATE: header will only work halfways: the calendar entry and filename will still reflect the date when the blog entry was made.

TIL: ppp makes better G3 connections if the SIM card is plugged in the proper way.

After procrasting about this for ages, I finally startet learning how use the RIPE ATLAS API, using the shell commands GET and json_pp.

The ripe.net web site has unfortunately moved into modern web-3.0 times, putting demands on a web browser which my lowly clients (midori, dillo, lynx) won't cope with. So today I learned to better learn further things in my office :-/