TL;DR: If you have a thing that's broken for you, contact me and we'll figure out a fix. If you have a DB-based thing or a PHP-based thing, this is likely.
If you have a thing that's broken for you, contact me and we'll figure out a fix. If you have a DB-based thing or a PHP-based thing, this is likely.
Upgrades last night went well, but a few things are being weird.
For some reason, pkg upgrade didn't reinstall proftpd. Easily enough fixed, but if it missed that, it may have missed other things.
Mysql didn't get upgraded from 5.5 to 5.6, but all the php stuff was linked against 5.6, so I manually upgraded mysql-server to 5.6 and ran a bunch of upgrade scripts.
Stupidly, the FreeBSD installer removed named.conf because BIND is no longer part of the base tree. DUMB. Like, there's no other reason a person would want that file? (Luckily, I had backed it up).
Also stupidly, trying to install bind9.11 tries to uninstall zkt. WTaF?
Freebsd-update wanting to overwrite my sendmail.cf (not MC, CF) was just plain dumb. Same with my ntp.conf. I think I'm just going to globally call a /usr/local/etc/ntp.conf in rc.conf, and let it stop complaining about any local changes.
Something tickles the password file that causes pkg's user-manipulations to fail, somehow getting the DB and the textfile out of sync.
People had warned me about my disk devices changing names, but as this is a VM with scsi-based vdisks this didn't affect me.
PHP no longer likes mysql's built-in "old style" passwords. If you have a site that's DB-based and you've been hosted by me for like a LONG time, I'll need to do some tweaking on the backend for you.
PHP's session dir got weird again. I may need to define a startup script to fix perms on that. (Come to think of it, I should define a crontab to do cleanup on that anyway).
As usual, there's a number of deprecated and "removed" PHP functions. I'm vaguely contemplating building static versions of older versions of PHP from scratch to try and resolve these. Because I use suPHP, it lets me determine the PHP interpeter at a per-site or even per-file level. In a past life, this let me run php4 and php5 at the same time.
(Yes, an unstable version of php5.4 sticking around is arguably bad, but if it's a thing I only turned on for a given site that was otherwise broken and that site runs only as that user, I consider this fairly low risk).
I've accepted that there's always going to be a couple of packages I need to build myself. That said, I should act like a proper port maintainer, and maintain "diff" files for them that are easily applied. I might even reach out to the official package maintainers on some of this stuff and see if they can be included.
Because this system started life using ports and pkg-classic, my packages have no idea which packages are "automatic" (i.e. were not explicitly installed, but merely installed as dependencies), so pkg autoremove may not work so well for me. At some point, I'll manually audit the dependency tree.
Squirrelmail's cert is marked as insecure because it's SHA1. I've put in for a reissue, but Geotrust is taking their sweet-ass time on it.
Now that I can support current state-of-the-art crypto, I'll likely do some cert tweaking for those things that use SSL. (Webmin, proftpd, Squirrelmail).
At some point, I really want to do a proof-of-concept that lets you accept weaker SSL settings, but redirect to a framed warning page. Because the default behavior of this (connection failed) just sucks.