Yes, I know. It’s been a long time coming. I’ve been thinking about it, but every time I considered building it, I opted to find real work to do, instead.
However, ImagePup has Automatic Thumbnails!. I’ve added code to resize the image and create a thumbnail for your specific image, with the dimensions of that image embedded within the image, itself.
I’ll eventually work on the ‘multiple file upload’ system, as well.
Eventually.
Debian Etch (the current stable distribution) is bundled with MySQL 5.0.32. While it works, there is a problem with replcating that data to other MySQL servers. This is fine for most users, however, I’ve built in a highly fault-tolerant enterprise.
As you’ll find, MySQL prior to 5.0.38 has a nasty problem: it will most likely mangle any AUTO_INCREMENT field’s value.
This is bad. People who write for MySQL use this almost extensively for an index key, and many rely on these numbers for sub-indexes. Something as simple as a ‘comment on this page’ form can be broken.
Fret not, though, for we can make our life easier (for now) by utilizing the 5.0.38 source package available within Sid’s repository, however, keep in mind that you should audit this to ensure it will work properly for you, as it has not completed regression tests:
First, make sure we’ve got adequate support software, libraries and headers to build our software (the below is somewhat cheating, but there are currently no major library changes required between Etch, and Sid):
# apt-get build-dep mysql-server wget dpkg-source # wget http://ftp.debian.org/debian/pool/main/m/\ mysql-dfsg-5.0/mysql-dfsg-5.0_5.0.38-3.dsc # dpkg-source -x mysql-dfsg-5.0_5.0.38-3.dsc # cd mysql-dfsg-5.0_5.0.38 # (fakeroot) debian/rules binary
You may now install the built binary packages.
I’ve seen this happen a few times, and it’s incredibly simple as to why: Somebody screwed up.
No. Really.
What’s happening about 90% of the time, is that there is a colission between installations. PHP usually uses a dynamic mysql library. Apache auth modules such as 2.2’s internal auth_dbd, and mod_auth_mysql also usually link against a dynamic mysql library.
If you happen to change your development mid-stream and don’t recompile everything, here’s where problems can occur.
To put it as non-geeky as possible: If the MySQL client is v5, and PHP uses this v5, but mod_auth_mysql is using v4, they both are asked to load, end up with with the same functions, and BAM.
It’s kind of like shouting “Hey, Steve!”, and having two guys answer “Yes?” The only difference is, UNIX doesn’t know how to act embarrassed and politely wave over the one that was intended.
Although, this analogy isn’t entirely true. It just makes it easier to understand. PHP wanted Steve v5, and mod_auth_mysql wanted Steve v4. So, when they both tried to call for Steve, both of them ended up in the same place.. which made bad things happen.
You can use ‘ldd’ to see which dynamic libraries are used by which programs, and other libraries.
# ldd /usr/lib/php4/20050606+lfs/mysql.so | grep mysql
libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 (0xb7d6e000)
# ldd /usr/lib/libaprutil-1.so | grep mysql
libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 (0xb7c56000)
Building limitipconn is fairly straight forward. It utilizes a simple Makefile build for the DSO object (which just uses apxs).
First, make sure you have all of the required libraries:
# apt-get install apache2-prefork-dev libapr1-dev
Here’s the simple diff from the default Makefile, to my modified one to ensure building. You can cut and paste this into vi, nano, or your favorite text editor, then apply to the Makefile included within the limitipconn package using patch:
—- Makefile.old 2007-04-27 17:50:57.000000000 +0200
+++ Makefile 2007-04-27 17:53:24.000000000 +0200
-4,12 +4,12## # the used tools -APXS=apxs -APACHECTL=apachectl +APXS=/usr/bin/apxs2 +APACHECTL=/usr/bin/apache2ctl # additional user defines, includes and libraries #DEF=-Dmy_define=my_value -#INC=-Imy/include/dir +INC=-I/usr/include/apache2 -I/usr/include/apr-1.0 #LIB=-Lmy/lib/dir -lmylib # the default target
All I did was update the Makefile to work with Debian’s installation for the utilities (differently ordered by the Apache major revision), and added the include directories, because the module’s author used indirect paths.
# cd /where/i/unpacked/limitipconn # vi Makefile.patch (paste in my above patch, save and quit.) # patch -p0 < Makefile.patch
Now, just make the module (This is almost cheating, but easier for folks not entirely familiar with the libtool build process):
#make install
Technically, it’s now installed. You can restart Apache and it will load. This isn’t 100% Debian friendly, as it uses /etc/apache2/httpd.conf, rather than the /etc/apache2/mods-*/*.{load|conf }heirarchy, but making it so is beyond the scope of this simple article.
I can, however, be coerced into doing so for money. ;)
If you haven’t noticed, yet, many of my recent developments have been for, and regarding Debian.
A current client is a RedHat Enterprise 4, CentOS, FreeBSD, and Debian shop, with Debian being on the front end. As the key systems are integrated to a unified OS approach, one of the most important aspects is to keep your front end systems up to date with security, first and foremost, then consistant features (with the legacy, where appropriate), and finally, new bells and whistles.
This ensures your deliverability; I can’t understand how large companies like YouTube manage to redirect people to a page saying ‘Sorry, guys, it’s that time of the week again. Everything’s down for a few hours.’
That’s awful design, and incredibly useless if your whole product is reliant on actually being available to make money.
Yet, I digress. This is now “Web 2.0” where the game seems to be “content over form.” All hail the new Emperor.. just as soon as he finishes touching up his body paint.