This describes how to build a LAMP platform on Suse Linux 9.3 64 bit with PHP 5.1.2, MySql 5 and Apache 2.2.0

The first thing to watch though is Apache does not build on 64 bit Suse. It has a bug in the apr-util configure that doesn’t let you use /usr/lib64. However, the Apache folks have provided a patch, which you can get from the site.

Apache

The first thing you must do is apply the patch to srclib/apr-util/build/apu-conf.m4:
http://issues.apache.org/bugzilla/show_bug.cgi?id=28205

This will get rid of the error:

/usr/lib/libexpat.so: could not read symbols: File in wrong format

The patch updates apu-conf.m4 to build an updated configure that knows what to do with a 64 bit directive. So, once you’ve applied the patch, you should delete the file:

srclib/apr-util/configure

and go back to the root directory of the source distro and delete the configure file there too.

Then, rebuild the configure scripts:

./buildconf

You now have a 64 bit enabled apr-util. To take advantage of it, you need to add this line to the root configure options:

–enable-lib64

Here’s the root configure in full:

./configure –enable-layout=UHI         \
            –enable-lib64              \
            –libdir=/usr/lib64         \
            –enable-rewrite            \
            –enable-so                 \
            –enable-ssl                \
            –enable-userdir            \
            –without-sendfile

I usually copy this lot into a file called configure_apache. So, all you need do now is:

./configure_apache
make
make install

PHP

The next pain in the neck is PHP, which doesn’t build under 64 bit cleanly either. It’s a bit of a juggle to get the paths right but if you set:

–with-libdir=lib64

and base the other modules’ directories on that it should work ok. You should be able to build PHP with most of what you want except for a couple of modules.

LDAP

openLDAP built fine out of the box with just ./configure, make, make install. However, when you use:

–with-ldap=/usr/local/openldap

PHP tries to find the openLDAP libraries in /usr/local/openldap/lib64. Only easy way to sort this is just symlink it:

cd /usr/local/openldap
ln -s lib lib64

That’s PHP and LDAP sorted.

MySql

As PHP5 doesn’t come with MySql, you need to download the client libraries and headers from the MySql download site. Our config required the Linux AMD64 libraries and headers.

The libraries end up in /usr/lib64 but although PHP can find them, the test code it creates doesn’t compile as it can’t find them! It almost seems as though the –with-libdir=lib64 doesn’t percolate down to the raw compiler level. When you try and configure PHP you get the error in config.log:

cannot find -lmysqlclient

Anyway, to sort this, just symlink again:

cd /usr/lib64
ln -s libmysqlclient.so.14.0.0 libmysqlclient.so

to create a .so file that the compiler can find.

Here’s the PHP configure in full:

./configure –with-libdir=lib64                      \
            –with-apxs2=/usr/local/apache/bin/apxs  \
            –enable-track-vars                      \
            –enable-ftp                             \
            –enable-sockets                         \
            –with-zlib-dir=/usr                     \
            –with-libxml-dir=/usr                   \
            –with-gd                                \
            –with-mysql=/usr                        \
            –with-ldap=/usr/local/openldap          \
            –with-openssl

This was a really strange one. The Guanxi SSO and AA share Principals via the servlet context, which groups all the servlets in a webapp and allows them to share information.

The SSO creates the Principal, puts it in the servlet context and the AA picks it up later to match it against a SAML Request.

Well, for some reason, the AA was getting the servlet context but the attribute set by the SSO was missing.

The IdP’s SSO is at http://guanxi.uhi.ac.uk/idp/SSO

Here’s what was wrong. In Tomcat’s server.xml, the IdP’s context wasn’t mapped. Instead, it was being defined by the default context:

<Context path=”" docBase=”idp”>
  …
</Context>

i.e. http://guanxi.uhi.ac.uk/idp/SSO was being mapped to the default context above.

Now, the WAYF was redirecting to http://guanxi.uhi.ac.uk/SSO, which mapped to the default context in Tomcat. However, the Guanxi SP’s metadata for the IdP was pointing to http://guanxi.uhi.ac.uk/idp/AA. As far as Tomcat was concerned the /idp context was different from the / context so the AA was getting a completely new context and not the same one the SSO was using. Hence the missing attributes.

The fix was to sort the config! First, fix the Tomcat context:

<Context path=”/idp” docBase=”idp”>
  …
</Context>

and then change the WAYF to point to http://guanxi.uhi.ac.uk/idp/SSO

and lo and behold the AA’s attributes came back!

java.util.ConcurrentModificationException

This error just appeared now and again, then it took over the machine and Tomcat would never serve SSL. Just blank pages. Well, turns out it’s a bug in Tomcat 5.0.28:

read about the bug here

To fix this, I got mx4j from the MX4J site and copied MX4J_HOME/lib/mx4j.jar to TOMCAT_HOME/bin/jmx.jar

I got to thinking lately about the amount of projects I’m working on at any one time. It’s calmed down a bit but at one point I was coding for 6 different projects, all at the same time.

Now, that doesn’t sound healthy, especially if you come from an exclusively waterfall model of development, where you work on one project at a time for months or years and you have a big party at the end of it, or not as the case may be.

Where do the roads fit in then? Well, they say that if you build roads, people will use them. Build a bypass and within a certain amount of time the bypass will be just as congested as the through route it replaced. Build ‘em and they’ll use ‘em.

The same is true for software skills. I learned this ages ago. I used to spend days and weeks at a time in kernal debugging with SoftICE and it was a relief to come up and spend some time in user land. During the spare time I had I’d explore the Windows API, the common controls and dialogs and build wee applications that didn’t do much except exercise that API. You know, exploring Zip files and tree views and all that. Pretty useless you’d think. Until a couple of weeks later, those skills would be needed. I’d need an installer for the drivers I was coding and lo and behold, I had a raft of API skills I could use and nice “unit tests” in the form of joke applications to remind me how to use them.

So the same holds true in software skills as in roads. Build ‘em and you’ll use ‘em.

Now to the bikes. Interval training. It’s a very effective way of building your fitness. Go out on a run, 100 miles or so, nothing too much and every now and then, go like the clappers, maximum effort, keep it up for 10/15 minutes, then relax back into touring pace. Every so often, do the same, ramp up the effort to max, push yourself to the limit, then relax again. Over time you’ll build up your stamina and fitness. OK, maybe 100 miles is quite a lot to start with. An evening 10 is fine.

How does this translate to coding though? Well, some people thrive on the variety of multi-project development and we rarely take on projects that are as different as chalk and cheese. So what we end up with is a portfolio of funded projects that are synergistic and exercise all our software skills. Spend a week or two on one project, thinking deeply about designs and solutions, doing some coding, some unit tests. Software interval training. Take a break, catch up on institutional housework, clear helpdesk calls. Then move on to the next project, taking the skills you built up in the previous intense interval to enlighten your decisions on the current project. Decisions that will build up to more interval training on the next project.

Multi-project development exposes you to many different problems that users encounter in the real world and these experiences feed back into your institutional knowledge. Your advice giving capabilities increase. If one of those projects is a large institutional one on a critical path, you’re in a position to draw on vast stores of skills and experiences to inform your decisions on that project to chart a path through to release.

Projects will also stall for all sorts of reasons outwith your control. Politics, dosh, hardware but you use the time to build some more skills, which you’ll use, guaranteed. You’re also keeping abreast of the latest developments in the area in which your projects operate. You’re spread within a discipline. Not to extremes. Just enough keep you interested and your brain ticking over and to be a useful oracle of knowledge to your institution.

So although multi-projects are probably not the norm, some people thrive on the challenges of real-time management, iterative development and extreme programming pratices. To say nothing of the constant building of knowledge and skills, which you know will be used in future projects.

So if you’re one of those people and you think you’re overworked and undervalued. Sod it.

Start laying the tarmac and get out on that bike!