It quickly comes out with Ensembl 16. I am not sure of the new features of this version, but ensembl side is fast as one version each month. The speed keeps Allison and I busy all the time. The most different thing of ver 16 is it runblast.pl. It needs to be able to start from each node.
In previous Ensembl versions, cluster jobs are as simple as invoking “blast” from each node. BLAST is a binary file and the configuration/data has been distributed to each node under /usr/local/ folders. Therefore, we have little problem with it.
From Ensembl 16, Blast jobs are wrapped by “runblast.pl”, which reads the config.packed configuration file and requires all the Ensembl perl modules to run. It needs all the ensembl codes to be visible across the cluster, meaning that it MUST reside in a NFS shared folder. This makes me a headache.
Besides of this, web server alwasys runs as un-privileged user “www” while config.packed, error_log and access_log files are the output of ROOT. If we start Ensembl 16 from the Web server and it tries to create the above three files as ROOT@Web-server. It definitely fails because ROOT@Web-server cannot overwrite files belonging to ROOT@NFS-server, unless Web-server is NFS-server as well.
To meet the requirement for Ensembl 16
- web code on a NFS shared folder visible to all the nodes
- web server must be one of the nodes
- NFS share must be over-writable by local root on each node
After several unsuccessful trials, we decide to put the web code on /nfs2 and change the NFS share configuration accordingly. The key is to remove “map root user to nobody” in “Workgroup Manager”. With this configurtion, local root user on the NFS client can overwrite the files in the NFS share.
It is bad for security, but I have no choice.