VDT 1.7.0 will be released today or tomorrow. We are working on a few lingering issues with RHEL 5.
Syslog-ng has been added to VDT 1.7.0. Currently, it is installing, and there is a configure script provided to help with generating the configuration files. There is currently some manual configuration required (specifying which logs to monitor), and there may be some configuration issues to deal with.
The VDT 1.7.0 and 1.7.1 releases will not have the Globus security update that was released in 1.6.1i. This will be incorporated in 1.8.0. This was a relatively minor security update, and we do not expect many people to install on public machines. It would have delayed the releases of 1.7.0 and 1.7.1 to get this security update in place. VDT 1.8.0 should include Globus 4.0.5.
Alan Sill asked about the latest VOMS version, since he is waiting on 64-bit support. We encountered some problems with testing of the new VOMS version (that provides 64 bit support). We have contacted the developers, and are waiting for feedback. In the meantime, we reverted VOMS to the version that was included in 1.6.1 in order to release 1.7.0.
Alan Sill asked about running an init service compatible with the VDT. It is necessary to create a configuration script. For an example, look at the configure_apache or configure_mysql (these will be located in $VDT_LOCATION/vdt/setup directory if Apache of MySQL has been installed). The configure script should run vdt-register-service, as well as running any service specific configuration.
Alan Sill asked about an issue with running gsissh on port 22. SSH has stopped working on that port, and the concern is that the sshd init script was overwritten. When 'vdt-control --on --force' is run, if it needs to overwrite any non-VDT files, it will create a backup in $VDT_LOCATION/vdt/backup. Additionally, all information about copying files is recorded in vdt-install.log.
Some talk about adding a "killer" package to the VDT to kill monitoring jobs that are being launched at the same time as the job manager, but are not correctly dying. If Condor-G is used, it kills these jobs and does its own monitoring. Would this situation improve under the managed-fork job manager? (currently unknown)
Steve Tim had an issue with a LIGO user. This has been resolved.
The latest 1.6.1 release is 1.6.1i. The VDT team's email announcement of the 1.6.1i release accidently referenced 1.6.1e.