Thursday, August 6, 2009

Local machine, hostname, ssl / https would hang

I am trying to put lessons I've investigated and learnt up, not only as a record for myself, but also to help others. The web has solved so many of my problems and I want to pass on anything i know that can help.

I am a Mac user (Mac Mini running Mac OS X 10.5.7 currently).

I run JSPWiki WebApp through the Tomcat server and have the security policy set to https (SSL) for logins and editing. My server is kanga.local (Bonjour) and it has the IP address of

When I connect from any other local machine I'd log in straight away (go to http address and 'login' and 'pw' form would come up immediately). When I connected to it via the server using the server name (kanga.local) the browser would sit there saying "connecting to kanga.local" and sometimes eventually got there to the login screen (over https). It was unusable like this. If I put in localhost instead it would get to the login screen but logging in (post OK) then would revert to kanga.local and once again it would take forever.

Things I tried to work out what was going on (aswell as Google):
  • dscacheutil (Directory Services) showed me that Kanga.local had multiple IP addresses

bsmith@kanga RCS $ dscacheutil -q host -a name kanga.local
name: kanga.local
ipv6_address: fe80:8::21c:42ff:fe00:9
ipv6_address: fe80:8::225:ff:fef8:3034

name: kanga.local

  • traceroute - returned a result instantly and showed it took 1 hop so didn't help me at all

bsmith@kanga RCS $ traceroute -p 8443 kanga.local
traceroute to kanga.local (, 64 hops max, 40 byte packets
1 ( 0.403 ms 0.057 ms 0.081 ms

bsmith@kanga RCS $ ifconfig
lo0: flags=8049 mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet netmask 0xff000000
inet6 ::1 prefixlen 128
gif0: flags=8010 mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863 mtu 1500
ether 00:25:4b:b3:d6:20
media: autoselect status: inactive
supported media: none autoselect 10baseT/UTP 10baseT/UTP 10baseT/UTP 10baseT/UTP 100baseTX 100baseTX 100baseTX 100baseTX 1000baseT 1000baseT 1000baseT
en1: flags=8863 mtu 1500
inet6 fe80::225:ff:fef8:3034%en1 prefixlen 64 scopeid 0x5
inet netmask 0xffffff00 broadcast
ether 00:25:00:f8:30:34
media: autoselect status: active
supported media: autoselect
fw0: flags=8863 mtu 4078
lladdr 00:25:4b:ff:fe:b3:d6:20
media: autoselect status: inactive
supported media: autoselect
en2: flags=8963 mtu 1500
inet6 fe80::21c:42ff:fe00:8%en2 prefixlen 64 scopeid 0x7
inet netmask 0xffffff00 broadcast
ether 00:1c:42:00:00:08
media: autoselect status: active
supported media: autoselect
en3: flags=8963 mtu 1500
inet6 fe80::21c:42ff:fe00:9%en3 prefixlen 64 scopeid 0x8
inet netmask 0xffffff00 broadcast
ether 00:1c:42:00:00:09
media: autoselect status: active
supported media: autoselect

  • iStat Menus is a system monitoring tool that shows Network Interfaces. I noticed that it shows the interfaces that ifconfig shows. And when I bring an interface down it can no longer be seen in the iStat menu.

What I wondered was why the Network System Preference didn't do the same as ifconfig. Then I realised it does!. This would have saved me alot of time if I'd realised it.

Go to Network Preferences and you'll see listed down the left-hand, what are ultimately network interfaces. This picture shows the en2 interface active:

Now select the interface you want to turn off and select 'off' in the Configure drop-down.

And it will be disabled. It seems to take a couple minutes to ripple through the system. And I had to close the current Firefox tab and open a new one.

If this doesn't work then you'll need to use ifconfig to turn off the network interfaces as per Disable your network interfaces (Mac Tricks and Tips blog):

sudo ifconfig en2 down
sudo ifconfig en3 down

Saturday, July 25, 2009

JSPWiki RCSFileProvider exception

I've been using JSPWiki for atleast 5 years now. One problem I've had which I've just worked out is an RCS exception (when using the RCSFileProvider to version pages) that frankly pissed me off! It seemed to come up and for no reason. It looks like:

JSPWiki has detected an error

Error Message
RCS checkin failed
Place where detected
com.ecyrd.jspwiki.providers.RCSFileProvider.putPageText(), line 430

If you have changed the templates, please do check them. This error message may show up because of that. If you have not changed them, and you are either installing JSPWiki for the first time or have changed configuration, then you might want to check your configuration files. If you are absolutely sure that JSPWiki was running quite okay or you can't figure out what is going on, then by all means, come over to and tell us. There is more information in the log file (like the full stack trace, which you should add to any error report).

And don't worry - it's just a computer program. Nothing really serious is probably going on: at worst you can lose a few nights sleep. It's not like it's the end of the world.

The problem for me was that I was previously running Tomcat as root and since then have started running it as user www (a user that has no admin rights to any other part of the server thus reducing likelihood of security issues). And root had the page locked. The solution is simple.

* For page do the following when you try and edit and save a page and the above error is shown.
** For example the page is "useful_commands" which has the corresponding RCS file "useful_commands.txt,v"

$ cd /where/wiki/pages/are/attachments
$ sudo rcs -u useful_commands.txt,v # this unlocks the page owned by root - use sudo -u if not root (see next)
$ sudo -u www rcs -l useful_commands.txt,v # this locks the page as www (tomcat running as www)
Now hit refresh in your browser and the changes made should be saved

Alternatively you could unlock any files locked by root with an:

sudo rcs -u *v

But I've not tried this. I assume on files not owned by root it will do nothing. I leave the verification to you as an exercise!

Saturday, July 18, 2009

GNUPG / Pinentry-mac paste problem

This caught me out after installing Mac GPG 2 which includes pinentry (as in pin entry). I could not paste my passphrase into it. I googles for ages and tried installing pinentry separately. I looked for configuration files.

Hours later I found out you can right-click to paste!

Sunday, March 1, 2009

Subversion and case-insensitive file systems

And solutions to problems this can cause

I work on MacOSX and it along with Windows has a case-insensitive file system. This has caused me pain on a number of occassions.

It looks like this:

> svn st
? Apache2
! apache2

Caused by renaming the file.

This is usually easily solved by renaming the file back again, but if you do some commits or other commands it can seem to cause a problem where Subversion claims it is locked but 'clean' doesn't have any effect. But not all is lost.

However I don't have a linux box (something that will change soon) and the second didn't work for me. This worked:

> cd .. # parent directory
> mv <parentdir_name> <parentdir_name>x
> svn up <parentdir_name>

Then fix up any changed files from the directory that has the same (case-insensitive) file name. And delete the <parentdir_name>x.


This will lead on to me posting one day about how I use Subversion as my backup mechanism and to help manage my home directory across multiple machines.

Let me know if you are keen for me to write this up.


Why are we here?

This is my 6th blog and despite being a Software Engineer and geek, I've hardly blogged against my black art.

Can't wait to get started ...