Unreliable Tomcat
Tomcat has had a memory leak for at least a decade that I am aware of. If you deploy by copying a war file to the webapps directory, sooner or later Tomcat runs out of memory. It's hard to kill tomcat when it's wedged in this way, since the standard way of shutting down is to send a request (via the shutdown script). If Tomcat is too ill to listen to requests, you can't shut it down. Usually the solution is to find its pid and kill it from the command line. How to automate this? That is, I want to reboot tomcat automatically, even when it's wedged. It sure would be nice if there was a pid file... Well, there can be a pid file. Set CATALINA_PID to the path to a pid file you want tomcat to use, and the catalina.sh script (called by startup.sh) will do the right thing. Then, in order to get shutdown.sh to make use of the pid file, simply stipulate -force.

Labels: tomcat

3 comments

Eclipse Regular Expressions plugins

Whenever I need to use regular expressions in Java, I end up wasting time messing with them to get them to work. And because you have to write your regex as a String in Java, you have to escape all the backslashes. Pretty soon, it becomes really hard to read. What I would really like is a plugin that lets me test my regex dynamically.

Others have thought of this. So I installed a variety of them and tried them out.

First up, Eclipse Regular Expression Tester. Its update site is http://brosinski.com/regex/update After installing, it shows itself in the preferences as RegEx Tester. It provides a new view called RegEx Tester. After a little testing, it seems that it does its job. The view makes very inefficient use of screen real estate. The results of the "test" occupy too much vertical space.

I also did not like the way you have to configure regex parameters globally. When I'm doing regex stuff, it's different every time. I need to be able to tweak in a more immediate way.

Next is QuickREx. The update site is http://www.bastian-bergerhoff.com/eclipse/features

This one does a variety of flavors of regex (JDK, ORO, blah, blah, with Perl and awk varieties) fwiw. You can also keep the regex's and "test text" in a library.

This thing is even worse with screen real estate, but at least the options are available in the view so you don't have to go to the prefs to change them. There's also a dialog for constructing a regex by selecting components from dropdowns. This seems a little odd to me, since if you know the meanings of all the terms in the dropdowns, you almost certainly know a shitload about regex and you don't need this tool. Whatever.

Anyway, it's the winner so far, even though the "copy regex to Java String" button doesn't work.

On to Regex Util. Update site is http://regex-util.sourceforge.net/update/ This is all about Java-style regex's, so maybe less UI clutter? Anyway, this one has no prefs. The UI is nicely laid out: minimal. Options and flags are dropdowns, not a gazillion checkboxes. Unlike the others, this one does not show groups, but it does highlight the match as you select parts of the regex. This seems like a cool debugging tool. Besides, once can always go into "replace" mode and enter the requisite $1, $2 and so on.

And copying to a Java-style String works and the opposite function is available.

Yay! This one is the winner.

Labels: eclipse, regex

0 comments

Mumble or Skype?

We use Skype a lot at Industrial Logic. But we also use VNC, and if the person running the VNC server has a low upstream bandwidth, the voice quality is unusable. We thought we might give Mumble/Murmur a try.

As it happens, I have done a bunch of research on VoIP technologies and speech codecs, so when I saw that Mumble uses Speex, I knew that it is on the right footing.

Two thing need to happen in order to get to the point where we can do some tests. The first is to set up the server. The Windows download of mumble includes murmur, and there are RPMs and static builds of murmur for Linux-based systems. As it happens, MacPorts has a murmur install, so on MacOS it's a simple matter of

port install murmur

Configuring the server — something I have yet to try — appears to be documented, but the proof is in the pudding.

Just for giggles, I fired up mumble in an attempt to connect to a public server. It seems that much of the goodness of mumble comes from it being configured correctly. In particular, it needs to be trained so that the background noise-filtering works correctly.

I have not reached on conclusion on whether mumble can replace skype for my bandwidth-challenged brethren. If I get 'round to installing murmur, we can give it a try.

Labels: macos, voip

0 comments

Notes on making a simple auth app using Wicket

Follow the instructions here and add the junk to your pom. You'll need to add a repositories element in which to put you repository. I put mine near the end, after the build

Run mvn install

I prefer JUnit 4 to 3.8, so I removed the generated "variable" ref from my class path and added Eclipse's built-in library for JUnit 4.

To keep things consistent, I modified the pom to refer to JUnit 4.. Maybe I should have let the Eclipse build reference the Maven repo rather than Eclipse for its JUnit. Hmm.

Added "variable" ref for both swarm and wasp (sheesh - why two? This is so confusing) and changed my application to extend SwarmWebApplication as described in the swarm getting started doc.

Of course, Eclipse helped me out with the stubs of the overrides of the abstract methods, so on to filling them in.

So, starting with a bare-bones app, start adding security. Hmm. Not working.

OK, so start with the kitchen-sink security demo app and begin deleting unneeded code. Hard, because I don't have a project and have to rely on reconstructing one from the war.

Aaargh! Give up on swarm. The guy's dead anyway, so who's maintaining it?

So auth-roles is the next.

Generate a project using mvn. Modify the pom to include auth-roles:

<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-auth-roles</artifactId>
<version>1.4-rc4</version>
</dependency>

Then use mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true to make the eclipse project. Import into eclipse.

Copy gibblies from the "wicket-auth-roles-example" available on Sourceforge. (It's in maven too if you know how to get it. I don't.) It has a weird structure, not like the autogenerated one with the embedded Jelly, so that's why we have to copy/paste.

A couple little syntax errors: Stuff that's presumably changed in more recent releases. An overridden constructor needs to be deleted, since the thing it overrides no longer exists. Stuff like that.

And the source needs to be reformatted. What's with all this C#-like source formatting anyway? Sheesh, this is Java, guys.

Labels: java, macos

0 comments

PHP Again

Since my last post about PHP dev, Eclipse PDT seems to have matured a bit. So I am having a go at installing it.

First, I uninstalled PHPEclipse and the xdebug plugins, and installed PDT. The instructions, mysteriously, are quite complex. Find them here.

I had a very frustrating time getting dependencies to resolve properly, until I found a hint somewhere that suggested that my Eclipse install was "messed up." So I downloaded a fresh Eclipse for J2EE and finally got PDT 2.0 installed.

This came at the cost of all the gaziilion other plugins I had installed, like the Google App Engine support, Ruby and Python support and so on. Feh. I'll live.

I disliked all the UI clutter introduced by the xdebug plugin so, contrary to Paul Scott's advice, I am giving zend debugger a whirl.

It seems that PDT comes with the "client" end of the Zend debugger, so all we need is the server. These instructions purport to guide one through that.

Make a phpinfo.php file containing only and execute it to see what php thinks about itself and its world.

Follow the instructions in the readme that comes with the download. First, I copied ZendDebugger.so into /usr/local/lib. Then I made /etc/php.ini by copying the default found in the same directory. This is what I added:

[Zend]
zend_extension=/usr/local/lib/ZendDebugger.so
zend_debugger.allow_hosts=127.0.0.1, 192.168.1.0/16
zend_debugger.expose_remotely=always

I was also told to copy dummy.php into your Apache docroot, but I don't know why. I put mine in /Library/WebServer/Documents/

To confirm that it's installed, we use our phpinfo.php and search for "debugger". There will be a reference next to the copyright as well as an entire section of zend debugger-related info.

We need the client end of the debugger which is not provided by Eclipse for licensing reasons. Get it here. (The referring page is here.) Hmmm. It seems you can get it from an Eclipse update site as well.

Leopard comes without pear so we have to install it:

cd /usr/local
curl http://pear.php.net/go-pear > go-pear.php
sudo php -q go-pear.php

Note that the go-pear script is very fragile and pretty badly written. It is easily confused. Make sure you are in the directory you want it to install into (/usr/local in our case), or it will get things horribly wrong. When it's done, it will have fixed your php include_path too. Use pear config-show to see how it's been set up.

Now, to install PHPUnit, all we need do is

sudo pear channel-discover pear.phpunit.de
sudo pear install phpunit/PHPUnit

It turns out that PDT does not support running PHPUnit directly, so I created an "external" run configuration in Eclipse to make it happen. [how? Maybe I'll fill in the details some time. Not now. It's my blog and I will write what I like.] I can finally test-drive some code! Next, deploy it. Zend Framework likes to assume it's at the root of your docroot, so people typically create a virtual host to make that happen. I found that Zend Framework apps really want to see Zend on the include_path so we add it in php.ini. But first we put a copy of the framework in a central spot. I chose /usr/local. So the whole download lives in /usr/local/ZendFramework-1.8.1. We'll want a symlink to isolate us from version lockin, so inside /usr/local, I did a

ln -s ZendFramework-1.8.1 ZendFramework

Now my include_path looks like this:

include_path=".:/usr/local/PEAR:/usr/local/ZendFramework/library"

Then, in things like the quickstart app, I just went into the library directory and did

ln -s /usr/local/ZendFramework/library/Zend

Finally, in the quickstart, I did the requisite

php scripts/load.sqlite.php --withdata

as dictated in the quickstart readme, and the db was created. Still following the instructions in the quickstart readme, I created the virtual host. I put it into /etc/apache2/extra/httpd-vhosts.conf and uncommented the include in httpd.conf. I added the line in /etc/host but here's the thing: Add ::1 as well as 127.0.0.1 since, being a futurtistic Mac, it uses IPv6. Apache had trouble with permissions when my docroot was in my home directory, so my virtual host's docroot ended up being /Library/WebServer/ZendFrameworkQuickstart-20090430 If you have permissions issues (you will), look in the apache log and chmod everything in sight. Finally, the app worked! Next, I tried making an app from scratch using the zh.sh script that comes with the framework. It's a bit like the RoR script(s) and is used to generate a new app, a new controller, a new view, etc. I made a do-nothing app and voila! it worked!

zf.sh create controller auth 
zf.sh create action login auth
zf.sh create action logout auth --view-included=0

Still, the virtual host stuff has to be set up or nothing else will work. That's very troubling, as I can't imagine many ISPs being open to that level of messing with their Apache instance. More on that particular nightmare another time.

Labels: macos, php

0 comments

Notes on setting up an LDAP server

Install OpenLDAP if you don't already have it.
Use WebMin to configure it. The defaults are pretty good.
Do this so you don't get complaints on startup:
cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
restart TWICE. The first time there will be another warning. After that, no more warnings.

Install phpLDAPadmin. Copy the example config as described in the setup instructions.
To verify that it works, try this:
ldapsearch -x -b 'dc=montessorifamily,dc=com' '(objectclass=*)'

To verify the auth, do this:
ldapsearch -x -b 'dc=montessorifamily,dc=com' '(objectclass=*)' -D 'cn=Manager,dc=montessorifamily,dc=com' -W

The "-x" says "use simple auth instead of SASL"

Create the basic structure by putting this into a file:

dn:     dc=montessorifamily, dc=com
objectClass:    top
objectClass:    dcObject
objectClass:    organization
dc:     montessorifamily
o:      Montessori Family School
dn:     ou=addressbook, dc=montessorifamily, dc=com
objectClass:    top
objectClass:    organizationalUnit
ou:     addressbook

Do not use a cleartext password in slapd.conf or WebMin won't know how to auth. Use WebMin to set the password and it'll use the '{crypt]' syntax and all will be well. phpLDAPAdmin doesn't seem happy with simple auth. Change it, or change LDAP? 'person', 'inetOrgPerson', 'organizationalPerson' are part of core.schema And the plural of schema is schemata (or "schemas" in a pinch.) See OnLamp article This Linux Magazine article requires one to register at their site. There is more about security, schemata, and replication, so I ignored it.

Labels: ldap

0 comments

TurboGears? Hmmm. Try Django.

I'm going for 2.0.

Following the instructions here:

sudo easy_install -i http://www.turbogears.org/2.0/downloads/current/index tg.devtools

Naturally, I got complaints, so I had to do this:
easy_install -U setuptools

Nope. It seems that no force on earth can update the default MacOS install of setuptools, so I just deleted it. The newer one had been put into /usr/local/bin by previous attempts to update setuptools (which is what the error message told me to do.)

We're still gonna need db drivers, so
sudo easy_install MySQL_python

The driver for sqlite is allegedly already part of Python.

So back to the install of TurboGears. The 2.0 docs are full of talk of "virtual environments" which makes me queasy. The reason I'm doing Python is simplicity, and that shit is not simple.

Like RoR (and PHP's ZF as I discovered) there is a CLI tool that sets things up. It's called paster.

So we follow the directions here: http://turbogears.org/2.0/docs/main/QuickStart.html — very well written, btw.

paster quickstart
blah blah blah

This is hell! It's worse than the PHP stuff! I wanted to go Python for simplicity, but this is a Heavy Weight Framework. Sheesh. Oh, it looks like a nice enough framework, but I am not looking for a PhD in frameworks. I just wanna get my app out the door! And, most important, I need something that is ISP-friendly. I simply cannot imagine doing all these arcane gymnastics in a user directory without root access.

Along the way I did
sudo port install python_select

and I love it!

So a quick
sudo python_select python26
and off to install django:
sudo port install py26-django

Labels: python

0 comments