Yesterday, I switched the BB-Grid node at our site from Globus 3 to Globus 4. After my partially famous GT3 Nightmare Report, I expected everything. To my surprise, everything worked GREAT for the GT4 installation procedure. The Debian-specific installation guide is an easy step-by-step document, which worked perfectly for me. All the generated host / user certificates are re-usable, which makes the migration even simpler.

Due to the fact that we spend great effort in opening some firewall ports between the institutes, I didn’t want to have the same procedure again for the new WSRF services port (8443). Since MDS2 is a deprecated component, I simply reused it’s port number 2135 for the web service container. For this reason, the default arguments of the WS-GRAM tools do not work any longer:

* With default port for web container: `globusrun-ws -submit -c /bin/false`
* With MDS2 port for web container: `globusrun-ws -submit -F https://localhost:2135/wsrf/services/ManagedJobFactoryService -c /bin/false`

Like all the other times in the past, `sudo` wasn’t easy to configure. The error was to use an absolute path with symbolic link information in the configuration file. Anyway, the first time since GT2 I got useful log messages from $(GLOBUS_LOCATION)/var/container.log.

The integration of our Condor pool also wasn�t a problem � execute the according job manager setup script (in $GLOBUS_LOACTION/globus/setup/globus/) and use �-Ft Condor� in the above command line to specify the Condor scheduler instead of the Fork scheduler during job submission.