refactor for Unifi OS 2.x

[Lollaskates]

Hi, I've done a rather substantial overhaul on the structure and function of udm-le to better support UnifiOS 2.x

• Removed container dependency, as podman is no longer installed by default
• Removed on_boot.d dependency / cron dependency, in favor of a modern systemd service and timer. /data/ and /etc/ are persistent storage, so systemd services remain after reboots and upgrades making udm-utilities on_boot.d moot. The timer triggers both onboot (300s delay, like original) and every day (at 3am, like original). There is now an additional random delay of 0-300 more seconds, to further spread out the load on LetsEncrypt.
• Now requires modern lego release present in the working directory. This can be found on the lego git (https://github.com/go-acme/lego/releases), and we need the linux_arm64 release. Install Example:

  cd /data/udm-le
  wget "https://github.com/go-acme/lego/releases/download/v4.10.2/lego_v4.10.2_linux_arm64.tar.gz"
  tar -xzvf lego_v4.10.2_linux_arm64.tar.gz lego

• updated service restarts to match the new service names
• updated radius restart to target freeradius
• fixed environment variable loading method as we're no longer passing env vars to a container, and have to consume them within the script for lego to use them.
• modern lego added environment variables for amazon route53, so those have been added to the .env configuration

I have tested this with cloudflare for both ./udm-le initial, renew, and the timer invocation. However, there are a few things left that need to be tested (and potentially adjusted):

• unsure if freeradius is the correct service to restart for the radius option of service restarting. The certs for radius are both located at the original location '/data/udapi-config/raddb/certs' as well as within the freeradius config location "/etc/freeradius/3.0/certs". The current code logic still only writes the certs to the original location. Potentially have to add the freeradius cert location to the process as well.
• BUNDLE/Wifiman logic is untested, as I don't use it. please scrutinize and test the update_keystore() function.

Some Notes: The udm-le service should not be started directly. It's merely a registered service and instead, udm-le.timer is what actually triggers the service to run. You can look at the status of the service and associated timer with systemctl status udm-le.service and systemctl status udm-le.timer respectively.

If you need to check the output of recent automated renewal attempts by the systemd service, you can check the log output with journalctl -u udm-le. Example output:

Mar 03 19:33:31 UnifiDreamMachinePro systemd[1]: Starting Performs Lets Encrypt certificate renewal...
Mar 03 19:33:31 UnifiDreamMachinePro udm-le.sh[11955]: Attempting certificate renewal
Mar 03 19:33:31 UnifiDreamMachinePro udm-le.sh[11955]: /data/udm-le/lego --path "/data/udm-le/.lego" --dns cloudflare --email admin@REDACTEDDOMAIN --key-type rsa2048 -d REDACTEDDOMAIN renew --days 60
Mar 03 19:33:32 UnifiDreamMachinePro udm-le.sh[11955]: 2023/03/03 19:33:32 [REDACTEDDOMAIN] The certificate expires in 89 days, the number of days defined to perform the renewal is 60: no renewal.
Mar 03 19:33:32 UnifiDreamMachinePro udm-le.sh[11955]: New certificate was generated, time to deploy it
Mar 03 19:33:32 UnifiDreamMachinePro udm-le.sh[11955]: Restarting unifi-core
Mar 03 19:33:38 UnifiDreamMachinePro systemd[1]: udm-le.service: Succeeded.
Mar 03 19:33:38 UnifiDreamMachinePro systemd[1]: udm-le.service: Consumed 141ms CPU time.

Helpful systemctl commands if you aren't familiar:

systemctl status udm-le #check status of service. if you want to check the status of the timer, make sure you specify udm-le.timer
systemctl enable udm-le.timer #ensures the timer starts on boot
systemctl start udm-le.timer #starts the timer, allowing it to execute whenever the timer is configured to (3am, also on boot).

Example status of an active timer:

root@UnifiDreamMachinePro:~# systemctl status udm-le.timer
● udm-le.timer - Run Lets Encrypt renewal daily and at startup
   Loaded: loaded (/etc/systemd/system/udm-le.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Fri 2023-03-03 19:33:31 EST; 52min ago
  Trigger: Sat 2023-03-04 03:04:40 EST; 6h left

Hope this helps!

[kchristensen]

Wow, not one but two people decided to tackle this while I was on vacation! So we have a competing PR here that takes a slightly different approach: https://github.com/kchristensen/udm-le/pull/71

So as I've mentioned previously I'm not currently using my UDM but I do have it sitting on my test bench so I can help with a little testing, but I think before either of these approaches gets merged we're going to have to solicit some help from others for all the various cases you outlined above.

First off I like your use of the systemd timer (I didn't even know this was a thing, very handy) and ditching the on_boot.d dependency. I feel like this is the way to go because reduces the complexity of the install process.

However, looking at the other PR I like that approach for sourcing the lego binary vs forcing people to do that bit manually.

How would you feel about yanking that bit over into this PR?

I'm on the fence about maintaining the legacy support that the other PR has. On one hand it's nice for people who don't want to upgrade, however I feel like it's just delaying the inevitable, because people really SHOULD be upgrading to 2.x.

I think the goal for this thing moving forward should be:

1) Maintaining the lightest touch as far as OS system changes to try and mitigate chance of breakage on updates. 2) Minimizing the amount of steps necessary for initial installation, since the majority of the issues people raise are generally because the userbase does seem to have a fair amount of people who aren't super unix savvy.

Also not a huge deal but we're also going to need some README updates but I can swing that after we can solidify this PR and get some user feedback.

I'll drop a note in the other PR to have a peek here and we can see what other people think.

Thanks so much for taking the time to do this, I have been too busy to get around to it!

[Lollaskates]

That all sounds good to me!

• Added new install_lego command switch to force install the configured lego version in udm-le.env
• Added detection of lego installation to initial command switch, and install if its not present
• install_lego() downloads a lego version as configured in udm-le.env, and compares the SHA1 hash to ensure integrity

Note: I'm still placing lego within the managed /data/udm-le folder, as placing it in /usr/local/bin would conflict with the apt package placement of the binary. I think it's best to keep everything as light touch and encapsulated as possible.

[potto007]

For what it's worth, the lego package installs to /usr/bin:

root@DreamMachinePro:~# apt-file list lego
lego: /usr/bin/lego
lego: /usr/share/doc/lego/changelog.Debian.arm64.gz
lego: /usr/share/doc/lego/changelog.Debian.gz
lego: /usr/share/doc/lego/changelog.gz
lego: /usr/share/doc/lego/copyright

/usr/local/bin is typically used for installs not performed by package managers.

[kchristensen]

Ok cool, mind resolving this merge conflict and I'll get this merged into the development branch? After that I can clean up a few things and I can cut a beta release or something and we can see how it's working for everyone else.

[Lollaskates]

Conflicts resolved - feel free to take it from here post-merge @potto007. I'm not sure if /usr/ is persistent, which was part of the reasoning for keeping lego within /data/udm-le. If it is, you or @kchristensen can move things around or refactor as needed. Enjoy!

[kchristensen]

Awesome I'm going to merge this now and hack on some documentation and what not tonight. Feel free to PR up anything as y'all see fit into the dev branch!

[kchristensen]

I just yolo'd a bunch of changes into the development branch, primarily formatting and README updates, that I haven't tested as of yet. Let me know if you run into anything weird.

[kchristensen]

Had a bit to test, and pushed up some fixes. Seems to work, although the captive portal stuff doesn't seem to be working but I don't use it and don't have time to dig into it at the moment.