Rude installers

Warning: Rant ahead. I spent the best part of yesterday fighting to get a commercial bugtracking solution installed. It will remain nameless for now - although if you know the market, it shouldn't be too hard to guess which one it is. The installation routine in question is without doubt one of the rudest I've ever encountered, stopping just short of the current number one spot held by Cisco's VPN install on Mac OS X, due to the latters' spectacular star turn of defecating all over your /opt directory.

Firstly, it's a PHP product (although it actually started life as an ASP product on Windows - a quick peek at the source code reveals it has been run through an asp-to-php converter in order to provide a rough-n-ready Unix solution. Ugh!). It blows away your current PEAR install, and then tries to download four additional packages. Strike one - I don't particularly take too kindly to software changing parts of my filesystem without a warning, particularly when it could just ask you to upgrade yourself. It also doesn't take into account any webservers which may not have a direct path to the outside world - if you're locking things down, blocking processes from initiating outbound connections to the internet is a very good way of foiling many script-kiddy attacks.

After I allowed it to talk to the outside world, it mysteriously failed halfway through and didn't manage to download those additional modules. I then tried to download those modules manually and install them myself, only to run into another little present the installer had left for me - as a nice treat, it also renames your "pear" command to "pear_old" before it quits, which quite obviously leads to various things breaking all over the shop. Strike two - hey guys, if your installer is going to crap all over my system, it better clean up after itself and leave things in the state it found them. I have no idea why it chose to do this, but after I renamed the command back things seemed to work fine.

At least, until I go to the next part of the install. It wants some truly brain-damaged settings configured in php.ini and my.cnf. 50Mb post_max_size ? 600 seconds max_input_time ? Sure, no problem! What's the big deal with DoS attacks, anyway ? Suspiciously, it also wants MySQL to accept maximum packets of 50Mb. Again, this makes me feel uneasy, not just because there is no way on Earth it should normally be set that high; I've got the impression that the software is going to store file attachments in a database, which just makes me start foaming at the mouth just thinking about it. So, any thoughts I had about running this on a shared server went right out the window. Strike three - I'm going to have to try and isolate it's bad design decisions as much as possible from the rest of the applications on the server - including bunging it, a separate PHP install and MySQL server into it's own little ghetto.

But then fun doesn't stop there! It also includes a shared library extension that must be loaded into PHP. One problem - it's been linked against libraries that aren't even part of the stock Solaris install. Yup :

warning: ldd: stupid_library.so : is not executable
libstdc++.so.2.10.0 => (file not found)
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1

Oh, JOY. After hunting this down, it seems as if it was linked against libstdc++ library in the SFWgcmn package, which is part of the optional freeware CD for Solaris. I downloaded this, installed it and tried again. No joy. The stupid, brain-dead library hadn't been compiled properly with correct -L and -R flags passed to the linker - it had no idea how to find this library. I've run out of strikes now - by this point, I'd reached the descision that this installer needed to be dragged out round the back of the barn and shot in the head.

I then had to implement a LD_LIBRARY_PATH wrapper around my whole Apache process, and anything else that needed to run with this extension. This is is A Bad Idea(tm), but the alternative of dinking with CRLE, and thereby polluting the rest of my system with /opt/sfw/lib seemed far worse. So after all that, was it worth it ? Well, it's a little difficult to say, given how dog-slow the product is. This is on a server that is running around 90-97% idle for most of the time, but for some reason pages take a good 4-5 seconds to load in a web browser. When they say you need a PHP opcode cache, they aren't joking. This also isn't without it's problems, as the available PHP opcode caches out there are either seemingly abandoned, forks that are starting over from scratch, commercial and wildly expensive, or just crash a lot on Solaris. Actually, pretty much all of them do that last one - but that's a rant for another day. Installing APC helps a lot, but is still a little unstable. Time will tell if this has been worth all the pain, but first impressions and all that...