Ami Sapphire's Notices updates from everyone.
amisapphire: Updates! mariadb: 11.4.10 -> 11.4.12
amisapphire's status on Sunday, 31-May-2026 21:41:36 EDT
amisapphire: Forgot the MSI PRO Z690-A WIFI DDR4. (DDR5 and any non-WIFI versions as well.) However, it uses a third-party kernel sensors module, so I may not submit that one... and the original in-kernel module is... not all that great. Also, I should set up the ASRock J4125B-ITX for its sensors.
amisapphire's status on Saturday, 30-May-2026 14:40:54 EDT
Forgot the MSI PRO Z690-A WIFI DDR4. (DDR5 and any non-WIFI versions as well.) However, it uses a third-party kernel sensors module, so I may not submit that one... and the original in-kernel module is... not all that great. Also, I should set up the ASRock J4125B-ITX for its sensors.
amisapphire: Slowly collecting my custom sensors3.conf files for the following motherboards: Intel SAI2 Tyan Tomcat S2925/S2925-E ASUS P8H61-I R2.0 HP Pro 3500 Supermicro X9SCM-F The ones that are pretty much finished are the Tyan Tomcat S2925/S2925-E and the Supermicro X9SCM-F. The Intel SAI2 one is very messy and should be completely redone, the HP Pro 3500 one is preliminary and should not be used, and the ASUS P8H61-I R2.0 one should be cleaned up a bit, but is usable otherwise.
amisapphire's status on Friday, 29-May-2026 14:55:07 EDT
Slowly collecting my custom sensors3.conf files for the following motherboards: Intel SAI2 Tyan Tomcat S2925/S2925-E ASUS P8H61-I R2.0 HP Pro 3500 Supermicro X9SCM-F The ones that are pretty much finished are the Tyan Tomcat S2925/S2925-E and the Supermicro X9SCM-F. The Intel SAI2 one is very messy and should be completely redone, the HP Pro 3500 one is preliminary and should not be used, and the ASUS P8H61-I R2.0 one should be cleaned up a bit, but is usable otherwise.
amisapphire: Finally found out why the Apache httpd service would fail at boot: this server is dual-stack, and the web server's service would try to start before the IPv6 part of the network connection would be established. -- httpd.service: * Added network-online.target to After=, didn't work; * Added ExecStartPre=/bin/sleep 5 worked, but that just makes httpd delay start for 5 seconds... * ...so Restart=on-failure, RestartSec=1s, and StartLimitInterval=1min were to be added instead as a workaround.
amisapphire's status on Thursday, 21-May-2026 11:44:38 EDT
Finally found out why the Apache httpd service would fail at boot: this server is dual-stack, and the web server's service would try to start before the IPv6 part of the network connection would be established. -- httpd.service: * Added network-online.target to After=, didn't work; * Added ExecStartPre=/bin/sleep 5 worked, but that just makes httpd delay start for 5 seconds... * ...so Restart=on-failure, RestartSec=1s, and StartLimitInterval=1min were to be added instead as a workaround.
amisapphire: httpd.service: Unit : After now has network.target added. Hopefully this fixes the 'fail-at-start' after a system reboot.
amisapphire's status on Friday, 15-May-2026 13:30:17 EDT
httpd.service: Unit : After now has network.target added. Hopefully this fixes the 'fail-at-start' after a system reboot.
amisapphire's status on Friday, 15-May-2026 13:27:25 EDT
amisapphire: Goofed on the httpd.service file: KillSignal should not be mixed! KillSignal changed back to SIGCONF, KillMode should be mixed...
amisapphire's status on Friday, 15-May-2026 13:26:23 EDT
Goofed on the httpd.service file: KillSignal should not be mixed! KillSignal changed back to SIGCONF, KillMode should be mixed...
amisapphire: More changes to the scripts: * httpd.conf now has the mod_systemd module added and enabled (missed in the initial tidying up process for httpd 2.4.66). * httpd.service now properly supports systemd handling. ExecStart is also changed: FOREGROUND option now used.
amisapphire's status on Friday, 15-May-2026 13:18:50 EDT
More changes to the scripts: * httpd.conf now has the mod_systemd module added and enabled (missed in the initial tidying up process for httpd 2.4.66). * httpd.service now properly supports systemd handling. ExecStart is also changed: FOREGROUND option now used.
amisapphire: Updates! Security httpd: 2.4.66 -> 2.4.67
amisapphire's status on Friday, 15-May-2026 11:05:11 EDT
Updates! Security httpd: 2.4.66 -> 2.4.67
amisapphire: Welp, Apache httpd needs to be updated due to security issues...
amisapphire's status on Friday, 15-May-2026 10:30:58 EDT
Welp, Apache httpd needs to be updated due to security issues...
amisapphire: A bit of Ubuntu Server network config history: Ubuntu Server, like a lot of distros, stored network configurations under a single filename: /etc/network/interfaces. Of course, starting and stopping them was a bit different. With version 17.04, they changed it to netplan. Both IPv4 and IPv6 are handled there, and configs were stored under the /etc/netplan directory. Starting and stopping network interfaces changed as well. With version 19.04, they changed it again to systemd-network. They helpfully migrated the configs to the appropriate /etc/systemd/network directory and had 'netplan' in the filenames. (Uninstalling netplan would be a bad idea here; you need renderer: networkd in a netplan .yaml file instead.) -- That same year, I spent over 30 minutes attempting to migrate IPv4 over (IPv6 was successfully migrated and was disabled in netplan) but eventually gave up, mainly because I knew no better of the systemd-network formatting back then. So this pretty jank network interface setup that stayed for six years is a result of the double migration of interfaces.
amisapphire's status on Tuesday, 05-May-2026 01:15:21 EDT
A bit of Ubuntu Server network config history: Ubuntu Server, like a lot of distros, stored network configurations under a single filename: /etc/network/interfaces. Of course, starting and stopping them was a bit different. With version 17.04, they changed it to netplan. Both IPv4 and IPv6 are handled there, and configs were stored under the /etc/netplan directory. Starting and stopping network interfaces changed as well. With version 19.04, they changed it again to systemd-network. They helpfully migrated the configs to the appropriate /etc/systemd/network directory and had 'netplan' in the filenames. (Uninstalling netplan would be a bad idea here; you need renderer: networkd in a netplan .yaml file instead.) -- That same year, I spent over 30 minutes attempting to migrate IPv4 over (IPv6 was successfully migrated and was disabled in netplan) but eventually gave up, mainly because I knew no better of the systemd-network formatting back then. So this pretty jank network interface setup that stayed for six years is a result of the double migration of interfaces.
amisapphire: More tidying up the (quite) ancient scripts: * httpd.service no longer uses the apachectl script and now uses the httpd executable instead. * the netplan 00-installer-config.yaml file had a forgotten change for one of the network adapters. For the network setup, it's quite jank: IPv4 is handled by netplan and IPv6 is handled by systemd-network. This is due to a historical (2017) setup. Initial IPv4 migration to systemd-network actually broke this a few years ago (around 2019), and I never attempted to fix this since. It should be possible now, though. I also learned to not uninstall netplan at that time...
amisapphire's status on Tuesday, 05-May-2026 00:46:40 EDT
More tidying up the (quite) ancient scripts: * httpd.service no longer uses the apachectl script and now uses the httpd executable instead. * the netplan 00-installer-config.yaml file had a forgotten change for one of the network adapters. For the network setup, it's quite jank: IPv4 is handled by netplan and IPv6 is handled by systemd-network. This is due to a historical (2017) setup. Initial IPv4 migration to systemd-network actually broke this a few years ago (around 2019), and I never attempted to fix this since. It should be possible now, though. I also learned to not uninstall netplan at that time...
amisapphire: Forgot to mention: the HDD -> SSD swap is probably the main factor of cutting down power, the CPU/motherboard swap being second. I shaved off ~40W power usage by doing both.
amisapphire's status on Saturday, 02-May-2026 15:55:56 EDT
Forgot to mention: the HDD -> SSD swap is probably the main factor of cutting down power, the CPU/motherboard swap being second. I shaved off ~40W power usage by doing both.
amisapphire: The system upgrade is finished! I may have disabled the onboard video to make it headless on the OPNSense box, as now booting up the webserver will bring up the beep codes for that... maybe next time. Also, found out that the old swap partition was corrupted, so that was fixed. It's now possible to run future versions of MariaDB. However, version 11.4 will still be used for now.
amisapphire's status on Saturday, 02-May-2026 15:35:10 EDT
The system upgrade is finished! I may have disabled the onboard video to make it headless on the OPNSense box, as now booting up the webserver will bring up the beep codes for that... maybe next time. Also, found out that the old swap partition was corrupted, so that was fixed. It's now possible to run future versions of MariaDB. However, version 11.4 will still be used for now.
amisapphire: The drive arrived today, and it's pretty abused. ~53% life left. This is fine to me, since this drive will not get a lot of writes from me, anyway. My current Silicon Power MLC SSD's life left is 32%. 😏 Anyway, it also sorely needed a firmware update. This fixes the following: - issue where the solid-state drive (SSD) does not resume from low-power mode - issue where the system fails to boot when it is not turned on for a long period I also updated the firmware of a Toshiba MQ01ACF050 500GB 7200RPM drive due to the following: - Improved the shock handling capability of the hard drive in power-on state. This server will be offline May 2, 2026 for the system migration.
amisapphire's status on Friday, 01-May-2026 15:32:06 EDT
The drive arrived today, and it's pretty abused. ~53% life left. This is fine to me, since this drive will not get a lot of writes from me, anyway. My current Silicon Power MLC SSD's life left is 32%. 😏 Anyway, it also sorely needed a firmware update. This fixes the following: - issue where the solid-state drive (SSD) does not resume from low-power mode - issue where the system fails to boot when it is not turned on for a long period I also updated the firmware of a Toshiba MQ01ACF050 500GB 7200RPM drive due to the following: - Improved the shock handling capability of the hard drive in power-on state. This server will be offline May 2, 2026 for the system migration.
amisapphire: Follow up to the notice below, I was right, it was the Sony display. I touched up the diodes in the battery circuit on the Supermicro board, thoroughly cleaned it up, and powered it on. The display happened to glitch up at that time, so instead of rebooting the system, I turned the display off and back on again... and the display was normal again. I have two of these 20+ year old displays, and this panel is the first of the two... and it happens to have rare display issues, but the panel has no dying pixels, and the bezel is fine. It also has a matching back. The second one has (barely noticeable) dying pixels, but it functions perfectly otherwise... but it has a dent in the top right corner. It also has no matching back. I'm going to swap the power board and Tcon from the second one into the first one and retire the other display. Dad has the second one (which replaced the first), so it goes back to him after this. I'll have to retrieve another display for the retro setup, it seems. http://cwcyrix.nsupdate.info/gnu-social/public/notice/232
amisapphire's status on Monday, 27-Apr-2026 18:24:42 EDT
Follow up to the notice below, I was right, it was the Sony display. I touched up the diodes in the battery circuit on the Supermicro board, thoroughly cleaned it up, and powered it on. The display happened to glitch up at that time, so instead of rebooting the system, I turned the display off and back on again... and the display was normal again. I have two of these 20+ year old displays, and this panel is the first of the two... and it happens to have rare display issues, but the panel has no dying pixels, and the bezel is fine. It also has a matching back. The second one has (barely noticeable) dying pixels, but it functions perfectly otherwise... but it has a dent in the top right corner. It also has no matching back. I'm going to swap the power board and Tcon from the second one into the first one and retire the other display. Dad has the second one (which replaced the first), so it goes back to him after this. I'll have to retrieve another display for the retro setup, it seems. http://cwcyrix.nsupdate.info/gnu-social/public/notice/232
CW Cyrix's Miscellaneous Website [The List]
amisapphire: Okay, ordered an SK Hynix SC311 128GB 2.5" SATA SSD for the replacement board. This actually delays the migration by about a week. It may also need a firmware update - specifically, a may not occasionally boot scenario. I also had an idea: relocating the database to another drive... again. I did this last time and it was a success, but it was with 2x 80GB IDE drives as a dm-integrity RAID 1 test. The database is on the same drive setup as the rest of the webserver data... which is not the system drive.
amisapphire's status on Sunday, 26-Apr-2026 16:47:51 EDT
Okay, ordered an SK Hynix SC311 128GB 2.5" SATA SSD for the replacement board. This actually delays the migration by about a week. It may also need a firmware update - specifically, a may not occasionally boot scenario. I also had an idea: relocating the database to another drive... again. I did this last time and it was a success, but it was with 2x 80GB IDE drives as a dm-integrity RAID 1 test. The database is on the same drive setup as the rest of the webserver data... which is not the system drive.
amisapphire: And... it also seems that I finally managed to get the board to keep its BIOS settings. That literally took over an hour to solve that. It originally started with it not responding with the power button, then eventually I walked off to retrieve something (over two minutes), then tried again and realized it powered on... Set the time and date, exit, power off the board then the PSU... wait ~2 minutes, power on the PSU, then the board. Forgot its settings. Repeat this ad-nauseam between testing RAM for errors and CPU temp. Oh, and the display would glitch up at times. May have to retire that particular old Sony SDM-HS94P monitor. Earlier, I disabled the BMC by jumper; the BMC was still zombie-enabled, but now the BIOS would no longer acknowledge it. Odd. Eventually jumpered the Chassis Intrusion setting and then used the Set User Default settings in BIOS. From there, BMC was no longer running... The board is in standby; it needs a SATA drive before the system migration.
amisapphire's status on Saturday, 25-Apr-2026 18:48:20 EDT
And... it also seems that I finally managed to get the board to keep its BIOS settings. That literally took over an hour to solve that. It originally started with it not responding with the power button, then eventually I walked off to retrieve something (over two minutes), then tried again and realized it powered on... Set the time and date, exit, power off the board then the PSU... wait ~2 minutes, power on the PSU, then the board. Forgot its settings. Repeat this ad-nauseam between testing RAM for errors and CPU temp. Oh, and the display would glitch up at times. May have to retire that particular old Sony SDM-HS94P monitor. Earlier, I disabled the BMC by jumper; the BMC was still zombie-enabled, but now the BIOS would no longer acknowledge it. Odd. Eventually jumpered the Chassis Intrusion setting and then used the Set User Default settings in BIOS. From there, BMC was no longer running... The board is in standby; it needs a SATA drive before the system migration.
amisapphire: Yes, I have actually brought CPU temps down nearly 20° Celsius because the original thermal paste was bone dry.
amisapphire's status on Saturday, 25-Apr-2026 16:03:22 EDT
Yes, I have actually brought CPU temps down nearly 20° Celsius because the original thermal paste was bone dry.
amisapphire: After the CPU repaste: http://cwcyrix.nsupdate.info/gnu-social/public/url/54
amisapphire's status on Saturday, 25-Apr-2026 16:01:47 EDT
After the CPU repaste: http://cwcyrix.nsupdate.info/gnu-social/public/url/54
amisapphire: Before the CPU repaste: http://cwcyrix.nsupdate.info/gnu-social/public/url/54
amisapphire's status on Saturday, 25-Apr-2026 16:01:06 EDT
Before the CPU repaste: http://cwcyrix.nsupdate.info/gnu-social/public/url/54
amisapphire: Corrections: open 'case' -> test bench Xeon E3-1270 -> Xeon E3-1270 v2 Also, max temp hit 72° C this time.
amisapphire's status on Saturday, 25-Apr-2026 13:16:13 EDT
Corrections: open 'case' -> test bench Xeon E3-1270 -> Xeon E3-1270 v2 Also, max temp hit 72° C this time.
amisapphire: Ran a memtest, left for ~15 minutes, returned and saw that the CPU hits ~70° C on load... and that's on an open 'case'. Will repaste the CPU, but I may replace it with a Xeon E3-1270 at some point anyway.
amisapphire's status on Saturday, 25-Apr-2026 13:11:50 EDT
Ran a memtest, left for ~15 minutes, returned and saw that the CPU hits ~70° C on load... and that's on an open 'case'. Will repaste the CPU, but I may replace it with a Xeon E3-1270 at some point anyway.
amisapphire: The board works, though its IPMI is also very old and insecure. [Version 1.86! Latest official is 3.52 (was 3.38 but someone YOLO'd and is official now), though 3.64 exists.] Since I'm not going to bother updating it like I did with the OPNSense board, I'll disable it on the board with the jumper settings instead for now. Still haven't disabled it on the OPNSense board yet... http://cwcyrix.nsupdate.info/gnu-social/public/url/54
amisapphire's status on Saturday, 25-Apr-2026 13:00:28 EDT
The board works, though its IPMI is also very old and insecure. [Version 1.86! Latest official is 3.52 (was 3.38 but someone YOLO'd and is official now), though 3.64 exists.] Since I'm not going to bother updating it like I did with the OPNSense board, I'll disable it on the board with the jumper settings instead for now. Still haven't disabled it on the OPNSense board yet... http://cwcyrix.nsupdate.info/gnu-social/public/url/54
amisapphire: The replacement server motherboard has arrived. I haven't tested it just yet, however. Going to have to obtain a SATA drive, though. The board can also use a SATA DOM (Disk-On-Module), and those are usually of industrial spec.
amisapphire's status on Saturday, 25-Apr-2026 11:33:54 EDT
The replacement server motherboard has arrived. I haven't tested it just yet, however. Going to have to obtain a SATA drive, though. The board can also use a SATA DOM (Disk-On-Module), and those are usually of industrial spec.
amisapphire: Found out the other old drive CD image is questionable as well. Going to have to re-download it. So both 2021-era driver CD image downloads have mismatched checksums...
amisapphire's status on Wednesday, 22-Apr-2026 21:22:55 EDT
Found out the other old drive CD image is questionable as well. Going to have to re-download it. So both 2021-era driver CD image downloads have mismatched checksums...
amisapphire: Forgot to mention: found one questionable file (possibly slightly corrupt). It was a driver CD image. Moved that one to 'questionable'. One BCM/IPMI firmware was repacked and a few third-party source files were loose, so I repacked them into RAR files. There actually was one official BMC/IPMI .zip file that was packed a little over a week before the known good checksum one, so it was moved to 'old'. The files themselves matched the ones in the known good one, too.
amisapphire's status on Wednesday, 22-Apr-2026 20:14:35 EDT
Forgot to mention: found one questionable file (possibly slightly corrupt). It was a driver CD image. Moved that one to 'questionable'. One BCM/IPMI firmware was repacked and a few third-party source files were loose, so I repacked them into RAR files. There actually was one official BMC/IPMI .zip file that was packed a little over a week before the known good checksum one, so it was moved to 'old'. The files themselves matched the ones in the known good one, too.
amisapphire: Well, this future upgrade had me going through my archived stuff regarding the Supermicro X9SCM-F mainboard, since the OPNSense firewall uses one. I should turn off the IPMI/BMC on that, since I have not used it in over five years... It's not even hooked up, either. It merely adds ~2 minutes of boot time to the entire process... Anyway, found some missing BMC firmware and one newer BMC firmware on the Internet. I am also obtaining the rest of the driver CDs, since an earlier attempt was done when I didn't even have enough space in general.
amisapphire's status on Wednesday, 22-Apr-2026 19:56:14 EDT
Well, this future upgrade had me going through my archived stuff regarding the Supermicro X9SCM-F mainboard, since the OPNSense firewall uses one. I should turn off the IPMI/BMC on that, since I have not used it in over five years... It's not even hooked up, either. It merely adds ~2 minutes of boot time to the entire process... Anyway, found some missing BMC firmware and one newer BMC firmware on the Internet. I am also obtaining the rest of the driver CDs, since an earlier attempt was done when I didn't even have enough space in general.
amisapphire: I was just made aware that the Rev. C2 version of the AMD Phenom II X4 945 can be 125W TDP (most are 95W TDP), so that part is correct. So it does not account for the 95W Rev. C2 or C3 version of the CPU...
amisapphire's status on Monday, 20-Apr-2026 13:11:22 EDT
I was just made aware that the Rev. C2 version of the AMD Phenom II X4 945 can be 125W TDP (most are 95W TDP), so that part is correct. So it does not account for the 95W Rev. C2 or C3 version of the CPU...
amisapphire: For fun, here is a comparison (the 125W TDP is actually wrong on the Phenom II; it's 95W): https://www.cpubenchmark.net/compare/1189vs7/Intel-Xeon-E3-1230-V2-vs-AMD-Phenom-II-X4-945
amisapphire's status on Monday, 20-Apr-2026 12:48:51 EDT
For fun, here is a comparison (the 125W TDP is actually wrong on the Phenom II; it's 95W): https://www.cpubenchmark.net/compare/1189vs7/Intel-Xeon-E3-1230-V2-vs-AMD-Phenom-II-X4-945
amisapphire: Found and ordered a motherboard + CPU + RAM combo to replace the current build this very webserver is using. Motherboard: Supermicro X9SCM-F CPU: Intel Xeon E3 -1230 v2 (3.30 GHz) RAM: 16GB DDR3 (when it arrives, I will note the exact specs) Current setup is the following: Motherboard: Tyan Tomcat S2925 (with S2925-E v2.01 BIOS) CPU: AMD Phenom II X4 945 Rev. C3 (3.00 GHz) RAM: 8GB DDR2 (HP marked, uses Micron chips)
amisapphire's status on Monday, 20-Apr-2026 12:47:38 EDT
Found and ordered a motherboard + CPU + RAM combo to replace the current build this very webserver is using. Motherboard: Supermicro X9SCM-F CPU: Intel Xeon E3 -1230 v2 (3.30 GHz) RAM: 16GB DDR3 (when it arrives, I will note the exact specs) Current setup is the following: Motherboard: Tyan Tomcat S2925 (with S2925-E v2.01 BIOS) CPU: AMD Phenom II X4 945 Rev. C3 (3.00 GHz) RAM: 8GB DDR2 (HP marked, uses Micron chips)
amisapphire: Finally found the reason the MariaDB 11.8 releases do not run on this quite old AMD server: the AM2/AM2+ architecture is too old. (It's missing the PCLMULQDQ instruction flag.) I went through the trouble of setting up a test server on a MiniPC (Intel NUC NUC6AYH), and it does run there. Though, I forgot to run lscpu for the instruction flags... so I searched for it online, and that NUC's CPU does indeed have the flag. I then actually compiled the source on an even older Dell Latitude D830 and executed it. Same illegal instruction (SIGILL) as on the aging server. It does not have the flag. It does run on my main laptop that has a high-end Sandy Bridge CPU, which has the flag. -- From the AMD server and main laptop logs: MariaDB 11.4: InnoDB: Using generic crc32 instructions MariaDB 11.8: InnoDB: Using crc32 + pclmulqdq instructions
amisapphire's status on Sunday, 19-Apr-2026 21:41:21 EDT
Finally found the reason the MariaDB 11.8 releases do not run on this quite old AMD server: the AM2/AM2+ architecture is too old. (It's missing the PCLMULQDQ instruction flag.) I went through the trouble of setting up a test server on a MiniPC (Intel NUC NUC6AYH), and it does run there. Though, I forgot to run lscpu for the instruction flags... so I searched for it online, and that NUC's CPU does indeed have the flag. I then actually compiled the source on an even older Dell Latitude D830 and executed it. Same illegal instruction (SIGILL) as on the aging server. It does not have the flag. It does run on my main laptop that has a high-end Sandy Bridge CPU, which has the flag. -- From the AMD server and main laptop logs: MariaDB 11.4: InnoDB: Using generic crc32 instructions MariaDB 11.8: InnoDB: Using crc32 + pclmulqdq instructions
amisapphire: Okay, MariaDB has updated config from 'medium' to 'large' settings (cribbed from MySQL 5.5 sample configs). I archived those configs for reference.
amisapphire's status on Thursday, 16-Apr-2026 02:47:24 EDT
Okay, MariaDB has updated config from 'medium' to 'large' settings (cribbed from MySQL 5.5 sample configs). I archived those configs for reference.
amisapphire: Was going through the server and deleting very old versions of compiled daemons and libraries; freed up ~5GB of space on the boot drive so far. However, I found an old .tar image of the server 'www' data from September 6, 2023, taking up ~548 GiB on the www-data RAID setup. (The final one is .xz'ed, taking up ~449 GiB on the NAS.) Thought I purged it years ago, lol. There's also some old HP laptop disk image on there from 2014 that I have never removed, taking up ~109 GiB; since copied to the NAS years later. Another ~800 GiB used up there is a bunch of Teknoparrot ROMs just sitting there as well. Very old versions of MySQL sit there; no longer can use them since the move to MariaDB. There's more decade [plus]-old cruft on that setup that existed ever since the server used a 4x 250GB RAID0+1 setup in the early 2010s. Removing a lot of it would free up probably ~2TiB of space.
amisapphire's status on Thursday, 16-Apr-2026 01:01:13 EDT
Was going through the server and deleting very old versions of compiled daemons and libraries; freed up ~5GB of space on the boot drive so far. However, I found an old .tar image of the server 'www' data from September 6, 2023, taking up ~548 GiB on the www-data RAID setup. (The final one is .xz'ed, taking up ~449 GiB on the NAS.) Thought I purged it years ago, lol. There's also some old HP laptop disk image on there from 2014 that I have never removed, taking up ~109 GiB; since copied to the NAS years later. Another ~800 GiB used up there is a bunch of Teknoparrot ROMs just sitting there as well. Very old versions of MySQL sit there; no longer can use them since the move to MariaDB. There's more decade [plus]-old cruft on that setup that existed ever since the server used a 4x 250GB RAID0+1 setup in the early 2010s. Removing a lot of it would free up probably ~2TiB of space.
amisapphire: Updated the structure of the *very* old httpd.conf file, as it was using the layout from version 2.4.33. This also makes my custom mime.types file finally obsolete. Also rectified the MariaDB update oversight, as I actually thought I did so yesterday...
amisapphire's status on Wednesday, 15-Apr-2026 21:43:22 EDT
Updated the structure of the *very* old httpd.conf file, as it was using the layout from version 2.4.33. This also makes my custom mime.types file finally obsolete. Also rectified the MariaDB update oversight, as I actually thought I did so yesterday...
amisapphire: Somehow, one of the PHP -FPM configs wouldn't stick (I changed the listen user/group entry to what httpd is using and it was stuck on default nobody...). I had to edit it locally and not from my laptop. 🤨
amisapphire's status on Tuesday, 14-Apr-2026 13:59:40 EDT
Somehow, one of the PHP -FPM configs wouldn't stick (I changed the listen user/group entry to what httpd is using and it was stuck on default nobody...). I had to edit it locally and not from my laptop. 🤨
amisapphire: Updates! openssl: 1.1.1w -> 1.1.1zg mariadb: 11.4.7 -> 11.4.10 Recompile: httpd 2.4.66 - due to external pcre2 and openssl updates php 7.4.33 - due to external pcre2 and openssl updates
amisapphire's status on Tuesday, 14-Apr-2026 13:56:09 EDT
Updates! openssl: 1.1.1w -> 1.1.1zg mariadb: 11.4.7 -> 11.4.10 Recompile: httpd 2.4.66 - due to external pcre2 and openssl updates php 7.4.33 - due to external pcre2 and openssl updates
amisapphire: Forgot: apr: 1.7.4 -> 1.7.6
amisapphire's status on Monday, 13-Apr-2026 23:15:20 EDT
amisapphire: Updates! httpd: 2.4.62 -> 2.4.66 Consistency Fixes... php 7.4.33: fpm now consistently runs on Unix sockets instead of TCP/IP:Port, meaning connections within PHP are even faster. This was mainly due to merging out-of-date configurations that I thought were up-to-date. [Was originally CGI for the longest -> FastCGI for testing -> FPM TCP/IP:Port -> FPM Unix Sockets] Other notes: MySQL/MariaDB did run on TCP/IP:Port due to Unix Sockets breaking at random historically, but that had been stabilized for at least a year.
amisapphire's status on Sunday, 12-Apr-2026 16:40:29 EDT
Updates! httpd: 2.4.62 -> 2.4.66 Consistency Fixes... php 7.4.33: fpm now consistently runs on Unix sockets instead of TCP/IP:Port, meaning connections within PHP are even faster. This was mainly due to merging out-of-date configurations that I thought were up-to-date. [Was originally CGI for the longest -> FastCGI for testing -> FPM TCP/IP:Port -> FPM Unix Sockets] Other notes: MySQL/MariaDB did run on TCP/IP:Port due to Unix Sockets breaking at random historically, but that had been stabilized for at least a year.
amisapphire: It was to the point that I isolated NetworkManager due to early assumptions that it was to blame. In the end, it is a years-old kernel bug. Yes, my main laptop's wireless setup is entirely manual now, and I can easily revert this.
amisapphire's status on Monday, 23-Mar-2026 13:03:49 EDT
It was to the point that I isolated NetworkManager due to early assumptions that it was to blame. In the end, it is a years-old kernel bug. Yes, my main laptop's wireless setup is entirely manual now, and I can easily revert this.
amisapphire: It seems that since around Linux kernel 6.6, newer Intel wireless cards will crash at suspend/wake... that is, unless you turned off the radio of the card entirely before suspending the system. My main laptop is still using Linux 6.2 (from 2023) due to this. I previously had 6.5, but some browser couldn't open with this kernel... No, this is still not fixed.
amisapphire's status on Monday, 23-Mar-2026 13:01:32 EDT
It seems that since around Linux kernel 6.6, newer Intel wireless cards will crash at suspend/wake... that is, unless you turned off the radio of the card entirely before suspending the system. My main laptop is still using Linux 6.2 (from 2023) due to this. I previously had 6.5, but some browser couldn't open with this kernel... No, this is still not fixed.
amisapphire: I honestly forgot about the rate limit settings! It was stuck on ~375KB average. This has been fixed.
amisapphire's status on Tuesday, 11-Nov-2025 21:57:37 EST
I honestly forgot about the rate limit settings! It was stuck on ~375KB average. This has been fixed.
amisapphire: We now have symmetrical upload since October 20 (known), but it may have been October 15. As a result, I have finally upped the bandwidth limit from 786KB/1MB (rest of main site) and 393KB/512KB (certain download sections) to ~5MB and ~2.5MB respectively. From there, stuff will be monitored occasionally.
amisapphire's status on Tuesday, 11-Nov-2025 20:43:05 EST
We now have symmetrical upload since October 20 (known), but it may have been October 15. As a result, I have finally upped the bandwidth limit from 786KB/1MB (rest of main site) and 393KB/512KB (certain download sections) to ~5MB and ~2.5MB respectively. From there, stuff will be monitored occasionally.
amisapphire: Finally have practically stable Live TV on Jellyfin 10.10.7! Quite recent Intel media drivers for Linux got it to that point. Other thing was Intel Core i3: 12100 -> 13100... but two pins located at the bottom-center of its socket on the board in question were quite bent. I managed to fix them perfectly, though.
amisapphire's status on Tuesday, 11-Nov-2025 15:04:14 EST
Finally have practically stable Live TV on Jellyfin 10.10.7! Quite recent Intel media drivers for Linux got it to that point. Other thing was Intel Core i3: 12100 -> 13100... but two pins located at the bottom-center of its socket on the board in question were quite bent. I managed to fix them perfectly, though.
amisapphire: Updates! mariadb: 11.4.5 -> 11.4.7 Cannot run 11.8.x on this server now due to SIGSEGV. A future version may run it. (26.04?)
amisapphire's status on Tuesday, 11-Nov-2025 14:50:54 EST
Updates! mariadb: 11.4.5 -> 11.4.7 Cannot run 11.8.x on this server now due to SIGSEGV. A future version may run it. (26.04?)
amisapphire: Updates! mariadb: 11.4.4 -> 11.4.5
amisapphire's status on Wednesday, 14-May-2025 04:12:00 EDT
amisapphire: Going to have to recompile PHP again as to have it no longer be thread safe. Also, pcre2 should be updated.
amisapphire's status on Friday, 22-Nov-2024 17:38:08 EST
Going to have to recompile PHP again as to have it no longer be thread safe. Also, pcre2 should be updated.
amisapphire: Updates! mariadb: 11.4.3 -> 11.4.4 Fixes... mariadb: tcp -> sockets Changes... php: fastcgi -> fpm (tcp) -> fpm (sockets)
amisapphire's status on Thursday, 21-Nov-2024 16:32:45 EST
Updates! mariadb: 11.4.3 -> 11.4.4 Fixes... mariadb: tcp -> sockets Changes... php: fastcgi -> fpm (tcp) -> fpm (sockets)