Nerding On Record

Since my last post, I did manage to achieve a working setup, providing wireless access further from my main router.  I'll describe the flaws later.

First wireless uplink config failed

When the router was in service previously, it had one SSID (network name) on the 5GHz radio, and a different one on the 2.4GHz band.  I even had disabled the one on 5GHz, because I was using a pro-grade Ubiquiti UniFi access point for that SSID, and kept the 2.4GHz one active for IoT devices and as a guest network.  Now, that SSID that was previously the guest/utility is the single network for the home, running on the UniFi AP (and both bands).  

Seems simple enough.  I set the 2.4GHz radio to AP mode, since it would be the one accepting clients.  It already had the right network name and password configured.  For the 5GHz radio, since I don't really need it to serve clients, I decided to set it to station bridge and just be the uplink.  But after changing the SSID to match the rest of the network, it wasn't connecting.  

Detour of managing the UniFi AP

From reading some notes about wireless bridging in the dd-wrt wiki, I guessed that my UniFi access point could be expecting different encryption than my repurposed router was set to use.  Previously I had set up the AP using the Android mobile app, but that doesn't give you access to all the detailed settings I would need to verify and change the encryption scheme.  (I realized later that I could have probably figured it out by looking at settings on a computer when connected to it.)

Ubiquiti sells you network controllers that manage multiple network devices, but they also let you download the software to run on your own server or workstation.  They seem to be in transition between two generations for this software, and my server was only compatible with the older one.  But eventually, I got UniFi Network Server installed, reset the AP, and joined it to the management console.  It even did a firmware update in the process, so that's nice.

Sadly, it didn't give me anything to select between TKIP and AES encryption.  Also, TKIP is mostly outdated, so I didn't really want that; I just wanted to know which one the AP was using.

Check the password again

I felt embarrassed when I looked back at the password that was set on the bridging router for the wireless network.  When I did a simpler version with the even older router, since it was single-band, it only had one place to put the password, and I was assuming the same, with the password already in there from when I had the separate infrastructure network with this same name.  But of course, two radios with two SSIDs means you have two places for a password, and my 5GHz radio was still set to a different password.  Just had to fix that, and on next boot, I was connected and working!

But the phones aren't so happy now

The main point was so that members of the household would have strong signal at the opposite end of the house from the router and UniFi AP, on their Android phones.  For some reason, they don't want to stay connected to the new AP, even where the signal is stronger.  I'm suspecting that it might be because Android really likes 5GHz a lot better than 2.4GHz, and is desperate to upgrade to faster signal even when it's weaker.

I wanted to keep using the 2.4GHz radio for clients, mainly for the IoT devices.  They seem to connect to the weaker signal of the UniFi though, just fine, so that isn't a requirement.

Haven't decided yet, but I have a couple options that don't seem ideal.

1. Switch the 5GHz radio to repeater bridge, and share that larger bandwidth with phones and the uplink
2. Switch the uplink to the slower 2.4GHz band

Option 1 seems to make more sense, just to see if the phones are more willing to use the extender that way.  And in reality, they shouldn't use enough bandwidth to choke the uplink, most of the time.

Yes, you can buy a basic wireless repeater for cheap, even at the Goodwill.  And while I'm writing this, I'm close to doing just that.  You'll soon see why.

There have been free replacements for the software on consumer-grade wireless routers for awhile, and dd-wrt is the king. I've run it for awhile at home, but it frustrates me off and on.  I even had one of my oldest single-band routers working as a wireless-client bridge (you have to plug into a wired port to get online).  I've since moved to semi-pro networking gear, but now I have a housing plan where running wires to add an access point isn't practical, and I have serious need of a wireless bridge and repeater in one.  And I have a faster router that ought to make it shine.

The specimen

I have a Linksys EA6400, from 2016.  It ran my home network for a solid 4 years (after a cheap pro router died early).  All internal antennas, but it has a USB port, and a gigabit LAN switch.  About a year ago, it started crashing and self-rebooting every couple of minutes, running 2024 firmware.

Unique flaws

This model is known in the dd-wrt world for both being tricky to get flashed to run dd-wrt from stock, and for overheating.  I had crossed the bridge to get it running open firmware years ago, but I feared the crashing was the overheating finally taking its toll.  I'm starting to wonder if the crashing might be from irreversible heat damage, or from the firmware version I'm on.

Following the guide on the dd-wrt forums, I opened it up, modded the heatsink, and got it back together.  It hasn't topped 70c since, but I haven't gotten it under much load yet.  Not sure yet if it will be more stable now.

So many extender configuration options

The first part of getting it to connect to an existing wireless network is deciding what mode to use, for there are many.

Station: A wireless client for the "WAN" uplink, and the thing acts as a router for the wired ports.  I think you can just let it do a second NAT layer, but I'm not sure if that's necessary to reach the Internet through the primary router.  For some reason this is easier to set up than bridging.

Station bridge: This is where it's a wireless uplink, but it makes wired ports act like part of the existing subnet, including getting DHCP from the upstream router.  I did this one with the ancient single-band router, but I reset it to be a spare wired router.

Repeater bridge: The magical full network extension, where it both serves as an uplink for wired ports and allows wireless devices to connect to it, while the uplink is wireless to a primary router that provides DHCP and Internet.  This is the desired effect.

My router is a dual-band radio, so it provides additional options, as to which frequency is used for the uplink, and whether one or both provides access to wireless devices.  The plan is to use the 5GHz radio for my uplink only, and set the 2.4GHz band to accept user devices.

Too much documentation

It's a classic case of everyone having an opinion: there are a lot of cookbooks out there to do this.  I thought I'd start with the authoritative guide, in the dd-wrt wiki.

[to be continued...]

First off, you can substitute "MariaDB" where I reference MySQL.  I'm not even sure which one is installed on the two hosting services.

Background:

I have some standard database-driven web apps installed on a low-cost web hosting service, plus my own home lab.  These apps have fully functioning copies installed and working on a second web hosting service that doesn't offer a command shell for administration, limiting me to their web-based tools like CPanel and Plesk.

Goal:

Replicate data from web apps over to their clones that run on the service with no Linux shell admin access, and automate as much of it as possible to happen daily/weekly.

Strategy:

I looked into MySQL/MariaDB native database replication features. It's possible to configure it to do real-time transactional replication between two hosts, but you need full access to the configuration files of the database engine on both servers, which isn't an option for shared web hosting.  Replacing my hosting with multiple virtual servers or containers would cost too much in both money and time.

A suitable compromise is to back up the databases on the source servers and send those to the duplicate servers, then load those backups into the database.  Then the trick is to do as few of those steps by hand as possible, to encourage me to keep it updated.

The web hosting service that provides shell access conveniently does automatic rotating backups of my databases.  They were compressed in ZST format (which I couldn't use on the target server) so I figured out the command to uncompress it:

unzstd backup/latest/app1_data.sql.zst -f -o tmp/app1_data.sql

On my homelab server, I did a mysqldump command to generate the backup file app2_data.sql.  [More on that later.]

Next was to get the file transferred.  The receiving hosting service doesn't have SFTP, just plain FTP.  It has to be passive mode, which seems common with cheap shared hosting.  It was working with the ordinary FTP command on my home server, but when I pushed the file from the shell on the other hosting service, it would give me an annoying error:

ftp> put app1_data.sql
local: app1_data.sql remote: app1_data.sql
200 PORT command successful
425 Could not open data connection to port 41069: Connection refused

I checked on the server and the file was there.  Maybe it was just failing to send my FTP client the confirmation or something?  Thought it was fine, but manual imports were failing with SQL errors.  I looked at the file at the destination, and it turned out they were truncated, maybe the last ~40kB was missing.

I remembered ncftp from my mental archives, and that was conveniently installed on the server!  That worked great, no more errors when uploading. 

To automate the upload:

ncftp has its own way of saving sites so you don't have to type in credentials when connecting.  But the mistake I made was using the server's actual DNS name for the ncftp "bookmark".  Problem with that is that if you say "ncftp ftpserversite.net" it just makes a new connection to that server and ignores your bookmark.  So I gave it a non-Internet-literal name.

ncftp> open ftpserversite.net

... [enter credentials]

ncftp> bookmark ftpserversite

Then in my script, I could reference the bookmark, with a single command to perform the upload.

ncftpput -R ftpserversite htdocs/phpmyadmin/upload/ tmp/app1_data.sql

I made backup shell scripts that did the extract and upload steps, on both the hosting site for app1 and my home server for app2.  So to recap for app1:

unzstd backup/latest/app1_data.sql.zst -f -o tmp/app1_data.sql
ncftpput -R ftpserversite htdocs/phpmyadmin/upload/ tmp/app1_data.sql

app2 on my server is more like this:

mysqldump -u [dbusername] -p'[dbpassword]' dbname_app2 >/var/backup/app2_data.sql
ftp -p ftpserversite.net <<END_SCRIPT
lcd /var/backup
cd htdocs/phpmyadmin/upload
rm app2_data.sql
put app2_data.sql
bye
END_SCRIPT

I did this one first, or I would have just done the whole ncftp bookmark thing and been done with it.  But plain FTP worked on the homelab, so I made a .netrc entry to store the authentication credentials for the FTP server.  Maybe I'll switch it to match the simpler one, but this retro version ain't broke...

Anyway, it was just a matter of scheduling these scripts to run periodically.  I set one to run weekly with cron on my home server.  The hosting site with shell access doesn't let you use cron directly, but they have a web tool to schedule jobs, so put the backup script there to run daily (I use that app more often).

Importing the data:

Maybe you noticed I put the file in an /upload folder for PHPMyAdmin.  That goes back to planning this whole thing: the web-tools-only hosting service has PHPMyAdmin built into their admin panel, where you can click and go straight to a specific database without having to authenticate again.  But the only way to import a backup file was to download it to your computer, and then upload it in your browser.  Lots of logging in and manual steps.  So... I asked an AI chatbot.  Not my favorite thing, and it didn't solve the need.

AI Fail:

I asked (paraphrasing here) how I could put a file on the server in my hosting account data with that particular service, and import it with PHPMyAdmin directly from the server, instead of from my computer/browser.  The answer was wrong in two ways:

1. It described and gave the wrong setting to configure PHPMyAdmin to allow importing files on the server
2. It said that the hosting service does not allow changing that setting to enable the feature, for security reasons

Crestfallen, I checked the PHPMyAdmin documentation for how to make that settings change.  That's how I discovered it gave the wrong setting.  What I really wanted to do was specify the name of the directory for uploads, and that's all it takes:

$cfg['UploadDir']='upload'

Then the second part was fun: sure, I can't modify the setup for the built-in PHPMyAdmin clickable buttons from their web panel.  But this host provides Softaculous, and one of the apps I can install is PHPMyAdmin!  I installed that in my account, created an upload directory, and then edited the config file, which had the UploadDir setting in there already but it was blank; I just filled it in like above.  That gave me a button on the import tab, with a drop down to select the files I uploaded, ready to rock.

Mission accomplished.

For the negligible cost and tools available, now I have "hot" backup duplicates of these apps. True, it doesn't do fully hands-off replication. But I have to sign on to their web admin panel monthly anyway to renew my LetsEncrypt certificates, so when I'm in there I just pop over to PHPMyAdmin (and I can grab the credentials from the admin panel), then refresh the databases from backup.  Pretty easy to maintain.

If either app has an outage and I want to start using the hot spare, I can either use it right away with slightly stale data, or go to PHPMyAdmin and refresh it from the backups that are already there.  I'm also assured that my backups work without tampering with the "production" site, and I can do upgrades on the hot spare first without risk.

Now I have two instances of Nextcloud that are behind on upgrades, but those are going to take some more work to sync before I feel safe upgrading.