That's a good point. I just might do that.

Update: It turns out the md5sum.txt files are put there by Debian's Live Build. Checksums are added on lb binary_checksum step of the build, which defaults to MD5 if no variable is provided to tell it otherwise. As Daniil suggested, we can put a second checksum step with SHA256 variable to produce both checksums, then check for sha256sum.txt files on new images. This way, old update scripts can still find an md5sum.txt in images.

Turns out vyatta-remote-copy.pl has been broken on Crux for a while. It fails to exchange encryption keys when it tries to establish an SSH connection (for SFTP or SCP), possibly because of the old libssh it relies on.

I'll give backporting a try. It should be doable as long as Paramiko is in our reach. If not, I'll see if I can cobble together something to check for hostname resolution failure.

MD5 checksums are generated by Packer at build time (configured in vyos-build). We can switch to SHA256 or SHA512 (which Packer supports) although it seems redundant when the install script also fetches SHA256 sum file (guessed by the ISO URL) and compares against that. I'd say configuring Packer to use SHA256 and omitting SHA256 files from download directories altogether would be the cleanest solution.

remote.py declaring support for TFTP and HTTP(S) might complicate things further. Since it's only for downloading, the latter shouldn't be too complicated to handle with urllib but if we need HTTP(S) uploading capabilities, an external library like requests would be preferable. As for TFTP, there's no support for it in the standard library, but instead of pulling in a third-party library for TFTP alone, we can just write an ad hoc wrapper for curl dedicated to TFTP. It wouldn't be as complicated since TFTP has no form of authentication so there's no need to worry about host keys and such.

VyOS is still on the ancient shell-based diagnostic file generator spaghetti inherited from Vyatta. First of all, I'm going to dike out {show,generate} tech-support from vyatta-op and write a rudimentary stub as a replacement in Python/XML. Then we'll need to discuss what exactly needs to go in there.

This PR does the switch over.

This PR adds the notification script.

It's better to let this problem be solved by the migration to pftables (per T3286) instead of try and a band-aid over this isolated issue.

I opened T3285 to it. Once the switch to shutdownd is done, I'll incorporate a service that warns the user of an impending shutdown.

This is caused by the omission of a call to conntrack --orig-dst in the new Python script.

I have successfully replicated this on 1.3-rolling-202101052023 and 1.4-rolling-202101240218. It's absent in 1.2.6. I'm going to investigate this regression.

Would it be too hard to hack the legacy config management script into using systemd for scheduling reboots instead of atd?

I can confirm that the issue of accepting configurations that yield errors is present in the latest LTS (1.2.6) and latest rolling release (1.4-202101240218). However, I couldn't replicate the issue of the configuration parser breaking at startup. Do we want to prevent the user from committing erroneous input at the risk of annoying false positives?