April 2020 Archives

Thu Apr 30 22:22:22 CEST 2020

  • read: nftables, Chapters 1&2
  • viewed: conference videos on Ceph (with occasional, careful looks into our own setups)

Posted by neitzel | Permanent link | File under: learned

Thu Apr 30 04:47:12 CEST 2020

Moving marshlabs mails around, and the RTFM! mailing list

Moving marshlabs mails around

I have several mailservers in my marshlabs network.

In the past, all mail for @marshlabs.gaertner.de addresses would eventually end up on host miles, a 486 box running FreeBSD-4.7. For decades, this was my main machine at home, but never running 24/7, these days just once a week or so. Miles gets the mail (and news) via UUCP from some other marshlabs box running 24/7 in the DC and acting as MX. In the last 25 years, these have been:

  1. ohura.gaertner.de, a SunOS-4 Sparc2
  2. spog.gaertner.de, a small Linux PC
  3. sco.marshlabs.gaertner.de, an SGI Indigo R3000 running IRIX-5.3
  4. ips.marshlabs.gaertner.de, a DECsystem running NetBSD-3.1 at that time
  5. hackett.marshlabs.gaertner.de, a VM running the current NetBSD release.

The MX would be aware of the ~30 addresses defined on miles for me, some accounts for friends, and a bunch of aliases for role accounts and small mailings lists.

The hackett mailhost is not just serving as a forwarder of the "marshlabs" mails to miles. I also handle all my NetBSD mailing list subscriptions on that system, some twenty mails per day.

In the last years, I peeked into my mails while they were still residing en-route in the uucp queue on hackett. Often, a simple more would be good enough, but in recent times various MIME encodings become more and more of a nuisance. In urgent cases, I would manually inject a copy of an mail destined to miles to my local account on hackett and deal with it directly, hopefully not forgetting to force the "@marshlabs.gaertner.de" sender address instead of the default @hackett.marshlabs.gaertner.de address.

In addition, I more and more originated mails from hackett but with the @marshlabs.gaertner.de sender adress. Sometimes I also used the hackett address openly for private mails to friends where a quick turnaround was beneficial and the manual re-routing too cumbersome.

A month ago I decided to do an experiment: deliver all mails to neitzel@marshlabs.gaertner.de directly on hackett. Keep on forwarding all other thirtiesh recipient addresses to miles via UUCP.

Following some mailing lists is mostly just a reading job. Dealing with my own mails is a bit more demanding, and I had a few doubts how the switch would work out.

The MUAs are both 4.4BSD mailx(1) derivations but not the same: Heirloom-mailx vs. NetBSD-mailx. They have slightly different approaches to more advanced things. Also: how much would I miss things from the miles system? All those mail boxes / archives, and other mail-related things (GPG keys?), perhaps some tools, would initially not be available. For example, on miles I can at least lynx HTML mails in the MUA -- not so on hackett. So, at the moment, I cannot really deal with mails from PayPal or the ACM New Contents listings. Not a huge loss, certainly not huge enough to make me tackle the magic decoder chain.

As an experiment, this is supposed to be reversible, but after four weeks I tend to stick with it and decided to move forward.

The RTFM mailing list

If you find a funny section in a UNIX man-page, send it to me! Even better: adhere to the to the fortune(1) citation style and send it to rtfm@marshlabs.gaertner.de, like this:

$ mail rtfm@marshlabs.gaertner.de
Subject: cdrecord(1)
BUGS
   Cdrecord has even more options than ls.
                                    --cdrecord(1)
.
$

Your submission will be

  • forwarded to a list of other people with a warped sense of humor,
  • incorporated in my "rtfm" fortune(6) collection.

If you want to be on that list yourself, just send an email at rtfm-request@marshlabs.gaertner.de. I will manually take care of your wishes.

You can probe the collection on the "quote-of-the-day" service:

$ telnet rtfm.marshlabs.gaertner.de qotd
Trying 2a00:1030:0:44::d90d:4185...
Connected to hackett.6.marshlabs.gaertner.de.
Escape character is '^]'.
Newfs builds a file system on the specified special file.  (We often
refer to the ``special file'' as the ``disk'', although the special
file need not be a physical disk.  In fact, it need not even be special.)
                                                       --newfs(8)

Connection closed by foreign host.
$

Yes. You want to have IPv6.


Posted by neitzel | Permanent link | File under: done, marshlabs

Wed Apr 29 13:13:13 CEST 2020

fossil unwedged

I track the the development of the Fossil version control system quite closely on one system (oker.escape.de). I do this for three reasons:

  1. I want to see how stable or instable this system is "on its bleeding edge",
  2. I wanted to check how good older or event ancient fossil versions I have in use on other hosts interact with the latest fossil,
  3. I want to see how the inventors/developers of fossil use fossil themselves. (Just like I monitor Linus Torvarld's comment on wrong or correct git usage on the LKML.)

The fossil sources are of course maintained with fossil.

I usually do at least one update per week, and very often a few. The systems is very stable on the trunk development branch.

Hower, I was missing any update for the last two weeks, and that was quite unusual. Also, the last changes related to the syncing of repositories, so was a bit suspicous. Checking out out the project site, there were indeed ongoing changes which I was missing. I was just sticking on my 2020-04-13 version.

The easy fix was to check out some version beginning of April, compile that and use it to sync to the current (April 29th) version, jumping over the hump.

This was the first time ever I had a problem with the fossil bleeding edge, and I track it for several years now.


Posted by neitzel | Permanent link | File under: done