Friday, December 22, 2023

OpenWRT, dnsmasq, dhcp, static mappings, but No DNS Resolution

The Problem

After poking around WAYYYYY too long to connect these dots, I finally have a reasonable explanation for why dnsmasq, running on on OpenWRT, absolutely refused to resolve an IP address from a hostname that was configured, in DHCP, with an IP for a specific client mac address.  The client machine was online, and reachable by that IP.

TL/DR

dnsmasq only resolves names from DHCP active leases, not from DHCP config.  (Read on if you need to know how to check, how to fix, etc.)

The circumstances were:

  • ip/name configured in DHCP for client machines mac address (as mentioned already).
  • client machine hostname configured to match the name also assigned by DHCP
  • client machine (linux) had been rebooted, after configuring DHCP and hostname
  • command dhclient -r issued repeatedly on the client machine
  • interface, domain, etc. set to "lan"
  • ipv6 disabled (just in case it was making things more complicated).
  • ping and nslookup from a different machine received NXDOMAIN response from dnsmasq/openwrt

Extra Circumstances (that didn't seem relevant, but were):

  • client machine had unexpired, cached DHCP lease info in /var/lib/dhcp/dhclient.eth0.leases
  • openwrt dhcp did NOT have an active lease registered in /tmp/dhcp.leases
  • dnsmasq had been restarted, the entire openwrt router had been restarted, and several updates had been "Saved and Applied" via LuCI.  This probably meant that any DHCP in-memory name:ip mappings were gone.

What fixed it?

On the client/host machine that can't be resolved/found by name...
  1. Delete /var/lib/dhcp/dhclient*.leases
  2. Reboot (because dhclient -r eth0 didn't help).

Verification

  1. Check that ping and nslookup now work as expected from other clients for the previously (let's hope) unresolvable hostname.
  2. Check that openwrt /tmp/dhcp.leases DOES now include a line for the recently, forcibly-renewed DHCP lease.

Explanation:

openwrt runs dnsmasq with a configuration that references the /tmp/dhcp.leases file.  
  • The setting is found on the Network - DHCP and DNS page in LuCI, on the Resolv and Hosts Files "tab" in the Leasefile field.
  • The setting is found in the /etc/config/dhcp file in the config dnsmasq section as option leasefile '/tmp/dhcp.leases'
    • See: https://openwrt.org/docs/guide-user/base-system/dhcp
    • This says: "leasefile stores leases in a file so they can be picked up again if dnsmasq is restarted."
    


Monday, December 18, 2023

Gogs: Internal Error from "git push"

This might have been fixed in Gogs, and maybe it just got me because I'm just running an older version, but I think it's worth a quick post here anyway...

Problem

Pushing a git repository to a remote hosted in Gogs... with ssh config, etc. all as it should be... results in:

me@myworkstation#:~/mylocalgitclonedir $ git push

Gogs: Internal error

fatal: Could not read from remote repository.


Please make sure you have the correct access rights

and the repository exists.

Cause

It turned out to be root:root ownership of the xorm.log file on the Gogs server.

In my case, running in a docker container, that was /app/gogs/log/xorm.log

This might be related: https://github.com/gogs/gogs/issues/4990

Don't know how this got changed in my particular setup... yet.  Maybe a backup or log rotation hiccup.

So, the cause was not: (including some of this for searchability of this article)

  • repository write permissions for user
  • SSH config on server or client
    • i.e. not an ssh client known_hosts error
    • i.e. not related to private key file permissions on the client
    • i.e. not using the wrong private key for the registered public key in gogs
    • checked with command:  ssh -v -T git@mygogshost

Solution

Open a terminal on the gogs host, and...

sudo chown git:git /app/gogs/log/xorm.log

After that git push worked fine again.

References

  • https://github.com/gogs/gogs/issues/4990

Tuesday, December 5, 2023

HomeAdvisor.com Password Reset

This info is current as of Dec 5, 2023, so if you're reading this later, and that was ages ago, it's not likely to be correct still.  So, with that said...

I just had the "wonderful" experience of trying to get logged in to HomeAdvisor.com on a mobile browser after initiating an account from a desktop web browser.

Their "clever" scheme to use a temporary login link, sent to an email address, instead of a password, makes it impossible to CHANGE your password once you are logged in, because you might have NEVER SET a password.  The "Forgot Password" link just sends you the non-password login link again... which is just another trip around their endless loop.

Called customer support and described the issue, and they just hung up on me, which might be an indication of whether you'd even want to work with HomeAdvisor/Angi in the first place.

The only way I could get out of the "catch 22" they created on the HomeAdvisor.com site, was to guess that maybe all of the the accounts are wired into the same place as Angi.com.  So, if you go to Angi.com's login page:  https://www.angi.com/login , you'll find a "Forgot Password? link that still goes to another page, which asks for your email address (i.e. login id), and actually sends you a link to reset your password on angi.com.  Magically, that ALSO sets your password on HomeAdvisor.com.

Since the idiots in customer support can't be bothered to help anyone figure out the !@#$% mess they've made of the logins between HomeAdvisor.com and Angi.com, I hope this helps, at least until they fix it, or (more likely) make it into an even bigger mess.

Friday, October 13, 2023

Legacy NVIDIA Driver for Ubuntu 20.04+

Summary

Either because an upgrade wrecked a working Linux install, or because the default drivers aren't performing very well, it may be necessary to install NVIDIA drivers for very old, "legacy" hardware on Ubuntu, or a similar Linux distribution.  This post is meant to help get that done without burning as much time searching for the right information and putting all the pieces together.

Symptoms

  • After an update / upgrade, Linux stalls mid-boot with a black screen and a blinking text cursor in the upper left corner.
  • Linux installed on a machine with older / legacy NVIDIA hardware is running too slow to be usable, and the graphics driver is suspected as the cause.

Elements of the Problem

  • Recent versions of Ubuntu install a kernel version that is no longer compatible with older NVIDIA drivers.
  • The default, generic driver doesn't perform very well (or at all) with older NVIDIA graphics card hardware.

Getting to a Terminal

When/if the X-Window / GUI Startup failed and stopped the bootup, it may be necessary to switch to another tty/terminal.  There are typically several of them started with Linux, and they can be accessed using CTRL+ALT+F2 (or F3, F4, ...).  From the blank / black screen with the blinking cursor, use that key combo to switch over and directly log-in to a terminal / tty, where the commands below can be executed.

Diagnostic Steps

  • Verify old NVIDIA hardware
    • Command:   sudo lspci | grep VGA
      • Should display information about the NVIDIA hardware (e.g. GeForce 9600M GT)
  • Verify old, no longer working, NVIDIA driver version is installed - (e.g. 340.108)
    • Command: dkms status
    • Command: apt list --installed | grep nvidia
      • Should show the NVIDIA driver package version (e.g. nvidia-340 ... 340.108)
  • Verify NVIDIA driver is malfunctioning
    • Command: nvidia-smi
      • Should report a failure to communicate with graphics hardware.
  • Check NVIDIA settings
    • Command: nvidia-settings
      • May report config errors, etc. and/or other useful info.

Elements of the Solution

  • Add the PPA repository from user kelebek333 which contains a version of the NVIDIA drivers that has been patched to work with newer kernel versions.
    • See: https://launchpad.net/~kelebek333/+archive/ubuntu/nvidia-legacy
    • Command: sudo add-apt-repository ppa:kelebek333/nvidia-legacy
  • Run command: sudo apt-get update
    • This should report that one or more packages (which include patched NVIDIA driver) are upgradable.
      • Verify w/ command: apt list --upgradable
  • Run command: sudo apt upgrade nvidia-340
    • This may report that there is a public key missing.  If so, run the following command replacing {key-value} with the key that is reported in the error message from apt upgrade...
      • Command: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys {key-value}
  • Reboot - If this resolved the NVIDIA driver issues, the X Window system should start normally again.