Automatic update of Fedora, not!

I tried doing an update of fedora the other day, with the dnf system upgrade business, to upgrade in place. I should have known better. The failure is almost certainly related to the ongoing frustration of the graphics card.

One is offered the choice of two nice poisons. One may elect to use the open source nouveau driver, in which case the graphics driver will spontaneously crash about once a week forcing a reboot. Or, alternatively, one may choose instead to install the proprietary nvidia driver, in which case every few months one will get a new kernel that invalidates the driver, and the machine will suddenly not boot at all, requiring that you get in a fool around with grub and intitramfs until you can get it up enough to download and rebuild a new nvidia driver.

The much ballyhooed DKMS which is supposed to solve this problem has never worked for me – that I know of. I suppose there could have been times when it magically worked and I didn’t have a hang, and didn’t know that I had dodged a bullet. But for sure I know when I do get the hangs.

And the worst time for all this is upon attempting to do the Fedora update. I knew I should not try it. It has always failed. I have specifically bought a little two drawer 2.5″ removable so that I can install onto a new SSD, and then switch back when it doesn’t work. But you never know – one of these days Fedora’s upgrade in place may actually work. Ubuntu seems to have their working reasonably well. And if I never try it on a new release of Fedora, I won’t know it has been fixed, if they ever fix it.

It took two days to get oregano back. In the meantime I had the problem that, for historical reasons (and stupidity on my part) oregano plays an essential part in the internal network. When oregano is down, dhcp is down, dns forwarding is down, the main firewall is down, etc. This has to change. See the next post.

Netfilter table order

II have a terrible time keeping this straight. This  is a memory aid. I think it is correct, but it has been assembled from internet sources and not from reading the code, so this is not authoritative.

  • Incoming packets:
    • NF_IP_PRE_ROUTING HOOK (PREROUTING CHAIN)
      • raw table [PREROUTING]
      • contrack
      • mangle table [PREROUTING]
      • nat table [PREROUTING] (dnat)
      • route decision (either for us, or another host)
    • IF Destined for this host:
      • NF_IP_LOCAL_IN HOOK (INPUT CHAIN)
        • mangle table [INPUT]
        • filter table {INPUT]
        • security table [INPUT]
        • nat table [INPUT (rarely used)] (snat)
    • IF Destined for another host:
      • NF_IP_FORWARD HOOK (FORWARD CHAIN)
        • mangle table [FORWARD]
        • filter table [FORWARD]
        • security table [FORWARD]
      • (-> do output postrouting)
  • Packets generated on local host:
    • NF_IP_LOCAL_OUT HOOK (OUTPUT CHAIN)
      • route decision (select interface, etc)
      • raw table [OUTPUT]
      • contrack
      • mangle table [OUTPUT (rarely used)]
      • nat table [OUTPUT (rarely used)] (dnat)
      • route decision
      • filter table [OUTPUT]
      • security table [OUTPUT}
    • (-> do output postrouting)
  • Output PostRouting
    • NF_IP_POST_ROUTING HOOK (POSTROUTING CHAIN)
      • mangle table [POSTROUTING]
      • nat table [POSTROUTING] (snat/masquerade)

contrack means connection tracking,  unless the (always preceeding) raw table says not to track.

In nat table, PREROUTING chain can only use -i and do dnat; POSTROUTING chain can only use -o and do snat. What you can do with the nat INPUT and OUTPUT chains I don’t understand well, but I think INPUT can do snat and OUTPUT can do dnat.

Difference of snat vs masquerade on nat POSTROUTING: 1) for snat you set the ip address, for masquerade you give an interface, and it uses the address from that interface. Also Masquerade assumes the connection will change ip address when it goes down and comes back up, so throws away all connections (contrack) information.

 

Certificates Redux

An earlier post talked about switching my server tarragon (where this blog sits) to a wildcard certificate from letsencrypt. There were two reasons why I was using a wildcard certificate. One had to do with test versions of websites that run on this server, and the need that some of those sites have for wildcards, of the form: bob.websitename.com, sally.websitename.com, etc. The other reason was that I have a lot of hosts (oregano, cinnamon, paprika, lemongrass) in addition to tarragon that “need” to have a certificate, for https, for imap, and for smtp, and when I was having to pay for them, it was cheaper to get one wildcard for wmbuck.net. Continue reading Certificates Redux

Dynamic DNS

I have used dynamic dns for around 20 years, I think. But I have always used dyndns.com which these days seems to want to call themselves dyn.com. And some years back they were bought by Oracle, the kiss of death, and now they are impossible to deal with, arrogant, unsupportive, insular – all the things I expect of Oracle.

And why have I kept using them? Because that is what the routers supported. Dyndns was  there first, and the ubiquitous linksys and netgear routers usually have a feature to do automatic updates for dynamic dns, but (often) the router will only update dyndns: nobody else. And I’ve got routers installed in various people houses that are doing this.

But I recently added a new house that I support, and that person has a proprietary and ponderous comcast router, which will barely do anything useful, and has no facility to update dynamic dns.

Continue reading Dynamic DNS

Apache Quiet Failure on Certificate/Key mismatch

In an earlier post I related how I had moved to letsencrypt for tarragon. In the process of doing some cleanup of the /etc/letsencypt directory, and my repository, I managed to stupidly get one wrong private key file into the batch of all the https vhosts, such that the http config file for xyz.com specified an SSLCertificateFile and SSLCertificateKeyFile which did not match.

It took me hours and hours to figure this out, because Apache simply fails to start and gives no indication whatever what has pissed him off. I wasn’t too stupid to figure out that I had been messing with the certs yesterday, and the problem might lie there somehow. But I have about 15 vhosts, so it was tedious. In the end I resorted to strace, and saw the problem.