|
What I did
NDS2 was not working on any of the machines, so the first thing I did was simply to install the newest version. I downloaded the latest tarball (0.9.1) from the LDAS Wiki, unzipped and installed it
/users/zach $ tar -xvf nds2-client-0.9.1.tar
/users/zach $ cd nds2-client-0.9.1
/users/zach $ sudo ./configure --prefix=/cvs/cds/caltech/apps/linux64 --with-matlab=/cvs/cds/caltech/apps/linux64/matlab/bin/matlab
/users/zach $ sudo make
/users/zach $ sudo make install
|
No no, this is totally unnecessary. NDS2 was already installed on every machine from the official packaged releases (apt-get install nds2-client), and it's known to work fine. We use it with pynds all the time. If the matlab component is not working we should figure out the right way to fix it with the existing packages.
In general, please only manually install software as a very last resort. Manually installed software doesn't get maintained, where as the officially packaged stuff is being actively maintained by the collaboration. If there is a problem with the distributed packaging we should report it and get it fixed (and hint I was the one who built the original Debian packaging for nds2, so I know how to fix all the issues). I'm trying to bring the 40m out of the dark days of complete chaos, where random software was installed in random locations.
|
Even with the new version, it still didn't work.
|
That's because this wasn't the problem!
|
Solution: The main problem was that the cyrus-sasl-gssapi authentication protocol was not installed on these machines, so that even with a kerberos ticket the datalink could not be established. Using information from the LDAS Wiki, I used aptitude to install it as:
$ sudo aptitude install lscsoft-auth
This group installs both the SASL protocol and the package python-kerberos
I also needed to update the kerberos config file for each machine, which is located at /etc/krb5.conf. I found that ottavia had a nice one with many realms, so I copied that one over to the other machines. In any case where there was an old config file overwritten, it is now /etc/krb5.conf.old.
Finally, the matlab path for NDS2 was still set to the old 2010a directory (/cvs/cds/caltech/apps/linux64/lib/matlab2010a) that was created by the NDS2 install when Rana originally did it. The new install I made above created the appropriate 2010b mexa64 files, so I changed the matlab path within matlab to this one:
>> rmpath /cvs/cds/caltech/apps/linux64/lib/matlab2010a
>> addpath /cvs/cds/caltech/apps/linux64/lib/matlab2010b
>> savepath
|
This sounds like it's more likely the issues. You did the right thing by going to apt to fix the authentication packages. It's curious to me that you did that here, whereas you went totally out of band for the nds2 client stuff. Why?
The matlab mex files are the other problem. But there is also a nds2-client-matlab Debian/Ubuntu package for that as well. The problem is that the package just distributes the source, and it needs to be compiled. I'll help figure out a good way to do that.
- I would like to extend this to the 32-bit machines, but I have to figure out the best way to install the proper NDS2 client without interfering with the 64-bit version. I think it is just a matter of specifying the matlabroot in the .../linux/ instead of .../linux64/
|
Again, this is handled by the packaging! Just use apt and the right architecture is installed automatically.
But what 32 bit machines are you referring to? I think basically everything is 64 bit nowadays.
- It would be nice to find a way that the nice tool gps('MM/DD/YYYY XX:XX:XX UTC'), which calls the ligotool executable tconvert, can be automatically usable when calling NDS2 functions. Right now, there seems to be an issue preventing that: even though tconvert can be run in the terminal, gps() returns an error and even directly running unix('tconvert now') or !tconvert returns the same error. I have emailed Peter Shawhan to see if he has any advice.
|
We are now using lalapps_tconvert for tconvert. We're not using that ligotools crap anymore. I've aliased that to tconvert on the command line, but maybe matlab isn't getting the message. I'll try to think of a more robust solution (e.g. make a wrapper script). |