Posted Monday, 03-Nov-2024 by Ingo Karkat
During breakfast, I read in Fefe's Blog that Synology has a critical vulnerability. Right afterwards, I log into my NAS to find 6 application updates, among them Synology Photos, the affected app. And that after enabling auto-updating since I recently updated to DSM 7; WTF?!
So, I update those applications manually, which takes half an hour. With little progress information, so it often appears hung (which to me is quite disconcerting, especially with a system that has no physical desktop attached). With confirmation dialogs in between, accepting third-party packages at my own risk (which I already did when I installed the apps). Debian and Redhat's package management systems do a much better job here.
Then I notice that a system update to DSM 7.2.2-72806 is available, too. I'm currently at 7.2.1-69057 Update 5, so (assuming semantic versioning) this should be a small patch release. As I'm doing system maintenance, anyway, let's pick that as well. The update is just a short download, but then it informs me about the move of some video encoding from the server to clients, and that the Synology Video app is discontinued, and please uninstall that app first before continuing. Eh, what?! If an operating system update forces the uninstallation of client apps, that's not a patch release nor a minor update. These changes should be reserved for major updates! (But then, the larger a system becomes, the less semantic versioning makes sense. IMO it's only truly useful for small components or micro services.)
So I read the changelog more closely, but there's nothing new to be learned. I google and find some user forums where angry users lash out at Synology for dropping support of the video app, and that it was one of the main reasons for choosing Synology in the first place, some discussions about third-party apps that could offer the same functionality, more hate towards Synology… Decision time! I had installed the Video app, and tried it a couple of times, but I'm not using it yet. I have some ideas for using yt-dlp to submit and then automatically download some YouTube videos onto my NAS, so that I can stream it from there, but right now I'm first experimenting with NewPipe to watch videos without the annoying ads (and without involving my NAS). I like the idea of the Synology ecosystem, but based on my occasional use of the Synology Audio app for Android, it suffers from poor usability (playlist handling), missing features (for me: no playback of WEBM files) and annoying bugs (occasionally skipping over some files in the playlist). So I'm not too keen to expand my use of them. Which means I favor staying on the latest DSM version over keeping the Video app.
After the reboot, the web interface is available and all appears well. But after logging in via SSH, my Bash profile complains about missing pgrep. Looking at my installation notes, I had installed that dependency via Optware. And since moving to DSM 7, the Optware setup appeared unstable:
01-Oct-2024 13:29 - Updated to DSM 7.0.1-42218 Update 6 via Control Panel > Update & Restore > |Download| Package Center says that "Easy Bootstrap Installer" and "iPKGui" need to be repaired, but doing so failed. 01-Oct-2024 16:54 - Install pgrep via $ sudo ipkg update $ sudo ipkg install procps (BTW $ sudo ipkg upgrade finds no updates!)
So it seems that the DSM update removed /opt altogether, and with that the ipkg binaries and tools like pgrep. Only the parts of Optware in /volume1/@optware/bin are still there. Some of its contents are actual binaries, but that directory mostly contains symlinks to the tools in /opt/bin. (Side note: The Frankensteinian grafting of stuff on top of stock firmware has been bothering me since the days of the Linksys NSLU2. I understand it's a necessary evil, but I often wonder whether I should instead just use a plain small PC with stock Ubuntu as a server instead.)
Fortunately, back then I already did a brief investigation that recommended the newer Entware over Optware, and had found simple instructions for doing so. And after a few minutes I was able to get back my pgrep via a simple $ sudo /opt/bin/opkg install procps-ng-pgrep.
During all the remote work on the system, I'd been hampered by the use of more instead of less as the pager, which caused problems with my smartless tool. This likely wasn't caused by the update, but with the big problems now out of the way, it's time to fix that as well. My Unix shell setup has been developed over close to three decades by now, and it allows an easy fix that consists of just a single-line local override of the pager.
This made me aware that the PATH modification in /etc/profile that gets overwritten by each system update should be better expressed by such a local override, too. No sooner said than done!
Log out and back in to confirm my changes, and… it still doesn't find pgrep! Well, it is in PATH in the interactive shell, but my customizations that run during login don't see it yet. Turns out that the simple appending to /etc/profile that the startup script for Entware is doing is too late; I need to load the Entware profile before sourcing /etc.defaults/.bashrc_profile (which triggers my profile loading). My addOrUpdateLine --add-after would be the perfect tool for this, but this runs as the root user (whose environment I'm hesitant to pollute with my customizations, especially on a closed system like Synology), so I instead opt for a crude sed insertion that assumes the export PATH is present (change highlighted in bold):
#!/bin/sh # Mount/Start Entware mkdir -p /opt mount -o bind "/volume1/@Entware/opt" /opt /opt/etc/init.d/rc.unslung start # Add Entware Profile in Global Profile if grep -qF '/opt/etc/profile' /etc/profile; then echo "Confirmed: Entware Profile in Global Profile" else echo "Adding: Entware Profile in Global Profile" sed -i -e '/export PATH/! b' \ -e 'a\ \ # Load Entware Profile\ . /opt/etc/profile ' /etc/profile fi # Update Entware List /opt/bin/opkg update
I'm finally done, but after a few minutes a lingering thought haunts me: I've read in the Entware documentation that it should be initialized as well as cleaned up. For my simple pgrep, this doesn't matter at all, but Optware / Entware offer a huge catalog of software, including middleware like databases which do like to be properly shut down.
Therefore, for completeness, I also create a second "stop" script. Should I ever impulsively install more complex software through Entware, my future self will thank me for that ;-)
DiskStation Manager > Control Panel > Task Scheduler
Create > Triggered Task > User Defined Script
General
Task: Entware stop
User: root
Event: Shutdown
Pretask: none
Task Settings
Run Command:
,----[ Entware stop script ]----
| #!/bin/sh
|
| /opt/etc/init.d/rc.unslung stop
`----
And this is how a short note read during breakfast occupied half of my morning.
Ingo Karkat, 03-Nov-2024
ingo's blog is licensed under Attribution-ShareAlike 4.0 International
