Indexing with Linux

HI all-

I use Linux at home, and I was thrilled when I read that I could help with the indexing at home, so I signed up and was able to index several pages of records. However, the next day, I was not allowed to get back to indexing. I even tried to work offline and it gave me a list of errors that looked Java related.

I really would love to help index, and I would love to support FamilySearch in this way, can someone help me figure out how to get back indexing? Should I just try to revolunteer?

Thanks!
Kate

What are the errors you are getting?

Tom

Hi Tom-

Thanks! Here is the error message I get when I hit work offline, after I get a message indicating that the server is unavailable:

java.lang.NoClassDefFoundError
at org.apache.axis.utils.XMLUtils.getXMLEncoder(XMLUtils.java:149)
at org.apache.axis.encoding.SerializationContext.getEncoder(SerializationContext.java:1700)
at org.apache.axis.encoding.SerializationContext.startElement(SerializationContext.java:1161)
at org.apache.axis.message.RPCElement.outputImpl(RPCElement.java:417)
at org.apache.axis.message.MessageElement.output(MessageElement.java:1208)
at org.apache.axis.message.SOAPBody.outputImpl(SOAPBody.java:139)
at org.apache.axis.message.SOAPEnvelope.outputImpl(SOAPEnvelope.java:478)
at org.apache.axis.message.MessageElement.output(MessageElement.java:1208)
at org.apache.axis.client.Call.invoke(Call.java:2757)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at com.iarchives.ws.usermanager.UserManagerSoapBindingStub.getCurrentUserAuxilliaryData(UserManagerSoapBindingStub.java:292)
at com.iarchives.iis.shared.IISAppData.readUserProperties(IISAppData.java:271)
at com.iarchives.iis.shared.IISAppData.ensureUserProperty(IISAppData.java:287)
at com.iarchives.apps.iude.IUDEAppContainer.goOnline(IUDEAppContainer.java:181)
at com.iarchives.apps.common.jobq.AppContainer._main(AppContainer.java:227)
at com.iarchives.apps.common.jobq.AppContainer.main(AppContainer.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.iarchives.apps.common.jobq.SplashMain.main(SplashMain.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1154)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1101)
at com.sun.javaws.Launcher.continueLaunch(Launcher.java:944)
at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:515)
at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:218)
at com.sun.javaws.Launcher.run(Launcher.java:165)
at java.lang.Thread.run(Thread.java:595)

Kate

I'm not in the Family History department so I can't comment on the error you are getting but from the looks of it, I'd try downloading the program again. By posting your error info, I thought it would help the FH guys track down the problem.

Tom

I don't know what's causing your particular error, but I would be interested in knowing what the problem was when you get it resolved. I have been able to do indexing on linux, though, so it is definitely possible.

Doug

HI Doug-

What version of Java are you running? I had it working on Opera, and I can't get it to work on Firefox at all.
I'd love to hear any ideas.

Hi Tom-

I've tried rebooting my computer, installing Java again, Installing the FamilySearch Indexing programs, changing my password several times.

I think the only thing we haven't done is uninstall Java and reinstall it.

Thanks guys.
Kate

I believe I had a similar error once. Try deleting the Java Web Start cache I believe the directory would be
If I remember correctly the problem came from going into offline mode. So I quit doing that and the indexing has worked pretty good since then.

Be warned it was a while ago I tried all this and any or all of it could be wrong.

Jonathan

Hi Jonathan-

Thanks, I will definitely try that.

ETA: It worked! Thank you so much. We are running Java 1.6 update 1

Kate

Can anyone give me some general instructions on how to get indexing installed on linux? I have java installed and have downloaded the indexing instalation file. I have installed it on a windows machine so I have the unpacked files available too. How do I go about getting it to run? I am fairly good with linux so general instructions should be sufficient.

Thanks

From a command line run the following command. The link below came from the "Install Now" button on the front page of familysearchindexing.org.
In the future you can run the program with the following command line.

Just a couple notes on using www.familysearchindexing.org with Linux - Specifically Fedora 7.

I got it working yesterday (28 July 2007.) Found a couple hurdles. Thought others might need to know.

1) Install Fedora 7.

2) Install better Java. You need better Java than provided by Fedora. Specifically, you need a javaws program. It doesn't appear to be part of the current Fedora Java environment. So, you need to install Sun's Java Runtime Environment (JRE).

With older versions of Fedora Core, I followed the Java install instructions in the Unofficial Fedora FAQ: http://www.fedorafaq.org/ but it is not updated for Fedora 7 yet. So I followed the Java install instructions available at: http://www.mjmwired.net/resources/mjm-fedora-f7.html

NOTE: That web page contains a variety of advice for Fedora 7 users. Not all that advice would be useful for all users. For example, I followed their instructions for: Yum, GCC Compatibility, MP3, Macromedia Flash, Java, and Kernel Headers. I passed on the rest. Other people, might have other needs.

3) Volunteer for FamilySearchIndexing. Bring up Firefox. Goto: http://www.familysearchindexing.org Click on "Volunteer" and fill out the form.

4) SKIP THE "INSTALL NOW" link on FamilySearchIndexing. All it does is install Sun's JRE. You should have installed the JRE back in step 2.

5) Tell Firefox to use javaws to interpet the iude.jnlp program. When you go to www.familysearchindexing.org and click on "Start Indexing", Firefox will start to download a file called iude.jnlp Then, Firefox will stop and ask you how to process iude.jnlp Tell Firefox to use the javaws program to process iude.jnlp I found the javaws program at: /opt/jre1.6/bin/javaws You may wish to tell Firefox to use this same program for this kind of file from now on.

6) If more than one username on your Fedora 7 computer wishes to Index, you need to address a bug. When the iude.jnlp program ends, it fails to remove a lock file. This file is located at: /tmp/iislock This file's protections are limited so only the username that creates it, can alter it. When a different username tries to Index, the iude.jnlp program will quit and give the message:
"Only one instance of FamilySearch Indexing can run at time."
"There is already an instances running."

Either manually delete /tmp/iislock every time you switch users (you might need to become ROOTly.) Or, change the permissions of this file so everybody can alter it with a

#chmod 666 /tmp/iislock

Happy Indexing!

Miles

miles wrote:
2) Install better Java. You need better Java than provided by Fedora. Specifically, you need a javaws program. It doesn't appear to be part of the current Fedora Java environment. So, you need to install Sun's Java Runtime Environment (JRE).

Miles

RedHat, and many other Linux distros include the GCC implementation of Java, not the SUN version. This could (and will) cause problems with many java programs.

You can get the SUN JRE from http://java.sun.com/.

The Earl

Really? Linux has its own version of Java? I wonder if there are some "Linux Only" extensions to the language. If so then what is different then Windows' Old Java VM which had windows specific extensions?

The Earl wrote:RedHat, and many other Linux distros include the GCC implementation of Java, not the SUN version. This could (and will) cause problems with many java programs.

You can get the SUN JRE from http://java.sun.com/.

The Earl

thedqs wrote:Really? Linux has its own version of Java? I wonder if there are some "Linux Only" extensions to the language. If so then what is different then Windows' Old Java VM which had windows specific extensions?

The "GCC implementation of Java", at least the gcc-java package distributed with Mandriva Linux 2007.0, is described as follows (in the package description):

This package adds experimental support for compiling Java(tm) programs
and bytecode into native code. To use this you will also need the
libgcj package.

It's different in the back end from regular Java in that it compiles to native machine code. I'm not aware of any extensions to the front end relative to regular Java in terms of language syntax or features. The last time I read about it, one of the Java graphics groups/packages (either Swing or AWX, I don't remember which) was not yet implemented. With Sun reportedly open sourcing most or all of Java, that may change.

Regarding the extensions that other big company did for its version of Java on its operating system, I seem to recall hearing that a judge agreed with Sun that they shouldn't have done that.

rmrichesjr wrote:Regarding the extensions that other big company did for its version of Java on its operating system, I seem to recall hearing that a judge agreed with Sun that they shouldn't have done that.

Who knows why then even did J#? I would pick C# over it anyday.

mkmurray wrote:Who knows why then even did J#? I would pick C# over it anyday.

Port your java programs over to the .NET platform. But yes I love C#, especially delegates where you can create a nice separation between application and module. (A project I am doing for my Machine Learning class requires this nice separation).

"GCC implementation of Java" or GCJ is a Java compiler not a runtime. It can compile java byte code or java code into native machine code.

Most Linux distros used to ship the Blackdown JRE/JDK. This was a build based on the public source distributed by Sun. Now that Sun has opensourced the whole lot I don't know where this will go.

I don't know that the Blackdown JRE had Java Web Start capabilities. When I have used FamilySearch indexing with my Linux machine it has always been with the Sun JRE. I found the Sun JRE to be faster than the blackdown JRE usually and a little more compatible. Some times the Blackdown JRE was behind a bit on having everything implmented.

Java has been open source for quite a while. However, SUN does not allow you to re-distribute JAVA. That is why most Linux distros do not bundle the JRE, since they can have the code, but they can't distribute it to a third party.

It is a bit odd to me that RedHat does not ship Java, as they do include licensed drivers and such.

Anyway,

First, thanks to those who have posted howto-type information about using the Indexing application on Linux. Unfortunately, it's not working for me. The application appears to download successfully, starts up, asks for username and password, puts up a "FamilySearch Indexing" window with File, Tools, View, and Help menu headings in the upper left, "online" in the lower right. The whole insides of the window are white, clicking on menu headings does nothing, and the window won't respond to the nice version of "close window" from the window manager menu. When the window comes up, something (presumably the indexing application) uses a few seconds of CPU time, and then the system goes idle. Nothing is using substantial CPU time, and there is no significant network traffic.

I'm running Mandriva 2007.0 and Sun Java 1.5.0_09 (build ...-b03). The indexing help page says it wants Java 1.5_11, which sounds like probably two tiny notches above what I have. Do we know whether the application is that picky about Java version?

My firewalls (Linux iptables and two hardware NAT routers in series) are set fairly tightly. Are there any unusual ports the indexing application needs to have open for data transfer? If that were the problem, would I be seeing the symptom of a blank window?

I have javaws, and it appears to be doing its thing correctly (except for starting Konquerer when I hit a wrong button...).

In ~/iArchives/logs/AppContainer-0.log, there are a bunch of INFO lines, a block of warnings apparently that ~/jobq.dat doesn't exist (which it does now), and a warning that log4j couldn't find any appenders for the logger.

Any other suggestions?

Thanks.

Java has some know problems (sounds exactly like what you are experiencing) if you are running Beryl or Compiz. The good news is that it is fixable if you want to recompile Java. Here is a document talking about it. Eventually you will find a site that tells you what you have to do to fix it. If you are running Beryl or Compiz, verify this is the problem by trying to run any java swing based application to see if you get the same problem. One of my favorites is Freemind.

Tom

tomw wrote:Java has some know problems (sounds exactly like what you are experiencing) if you are running Beryl or Compiz. The good news is that it is fixable if you want to recompile Java. Here is a document talking about it. Eventually you will find a site that tells you what you have to do to fix it. If you are running Beryl or Compiz, verify this is the problem by trying to run any java swing based application to see if you get the same problem. One of my favorites is Freemind.

Tom

Thanks for the suggestion. I think my case is different. I'm not running Gnome, KDE, Beryl, or Compiz. My window manager is twm. The "Here" test case puts up a window with "WM Test" displayed. Freemind brings up an editor with menus that seem to work. Indexing still gives a blank window (except for upper left menu headings and lower right "online").

rmrichesjr wrote:Thanks for the suggestion. I think my case is different. I'm not running Gnome, KDE, Beryl, or Compiz. My window manager is twm. The "Here" test case puts up a window with "WM Test" displayed. Freemind brings up an editor with menus that seem to work. Indexing still gives a blank window (except for upper left menu headings and lower right "online").

Sorry...I've exhausted my knowledge

I run on Kubuntu 7.10 and it works fine for me. I do have a later version of Java than you.

Tom

Is that the newest version of Java available for that platform? The older ones had vulnerabilities that could be exploited - regardless of they were Unix, Linux, Apple or PC.

RussellHltn wrote:Is that the newest version of Java available for that platform? The older ones had vulnerabilities that could be exploited - regardless of they were Unix, Linux, Apple or PC.

It was the newest available Java version when I installed it, but 1.6 is now available from Sun. I tried 1.6 with the non-RPM installation method, and it seems to get only a bit further. After entering my username (and password), it puts up two windows, the one with the menu items and a smaller one with a slightly darker background but nothing at all besides the light gray background. Running "javaws -viewer" also brings up two windows, the control panel and another blank light gray window. (Java 1.5 had shown a window apparently intended to show the cached/available/running applications.) I'll give the RPM installation method a try.

rmrichesjr wrote:Running "javaws -viewer" also brings up two windows, the control panel and another blank light gray window. (Java 1.5 had shown a window apparently intended to show the cached/available/running applications.) I'll give the RPM installation method a try.

It defnintely sounds like you have a problem with java, not with FamilySearch Indexing. When I run javaws -viewer I see the control panel (which you see) and then I see a listing of the java webstart programs in my cache. Since you can't see that, it would indicate something is messed up with your distro and java.

One other possibility is that you somehow have both the gnu java and the sun java installed on your system and for some reason when you are trying to run the sun java, it is picking up the gnu java. By default, the gnu java is installed and used with (k)ubuntu. Since the gnu java is not quite as compatible with applications as the sun java, make sure you are running the sun jre. To do this, execute the javaws with the full path to the correct jre. In my example, that was "/opt/jdk1.6.0_01/bin/javaws -viewer".

Tom

Thanks for your patience.

I installed Java 1.5.0_13. The GNU Java is not a problem, because those executables are not called "java" or "javaws". I did

/usr/java/jdk1.5.0_13/bin/javaws http://familysearchindexing.org/iis-apps/apps/iude.jnlp

After I entered my username and password, the application window is blank except for the top menu bar and the bottom status bar. It looks hung on something. Doing "lsof -i" shows

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
java 25120 rob 6u IPv4 3489006 TCP one.localnet:2467->64.90.195.26:http (CLOSE_WAIT)

The java application is hung waiting for network traffic. Whois says host 64.90.195.26 is owned by ViaWest Internet Services, Inc. in Denver, CO. Doing "traceroute -I 64.90.195.26" goes to hop 12 and stops:

11 gige-09-00.crrt02.slc03.viawest.net (206.71.65.42) 47.590 ms 46.764 ms 47.542 ms
12 vi-011.aggm01.slc03.viawest.net (64.90.192.38) 47.436 ms 46.816 ms 47.396 ms
13 * * *
14 * * *
15 * * *

My external IP address is in the 71.*.*.* block that was activated only a few years ago. For a while, I was not able to get to qa.mandriva.com because some router in France was failing to recognize 71.*.*.* as valid. Eventually, I complained in enough places to get somebody to fix the outdated router, and the problem went away.

This smells like the router in ViaWest territory just past 64.90.192.38 is failing to recognize 71.*.*.* as valid.

Besides complaining to ViaWest and reporting the problem to FamilySearch Indexing support, any other suggestions?

Thanks.

So if you were to take your machine to a different location that had a different IP address, I wonder if the problem would disappear. If your machine is a laptop, try taking it to some free wifi spot.

Tom

tomw wrote:So if you were to take your machine to a different location that had a different IP address, I wonder if the problem would disappear. If your machine is a laptop, try taking it to some free wifi spot.

Or perhaps an SSH Tunnel?

Aaron

rmrichesjr wrote: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
java 25120 rob 6u IPv4 3489006 TCP one.localnet:2467->64.90.195.26:http (CLOSE_WAIT)

The java application is hung waiting for network traffic. Whois says host 64.90.195.26 is owned by ViaWest Internet Services, Inc. in Denver, CO. Doing "traceroute -I 64.90.195.26" goes to hop 12 and stops:

The CLOSE_WAIT state means that the close process has started. The first of the FIN flags have been sent. So actually the program has finished communicating. If a program was waiting for data netstat would not show this. It would just show ESTABLISHED. This you would have to look to the program for that kind of information not the TCP stack. If the program could not connect you would probably see the SYN_SENT stuck until the timer expires.

FYI my computer shows the same traceroute. It is a firewall blocking the echo requests. You can see the same things with other providers that like to do that.

It also should be noted that the IP you were tracerouting is http://www.familysearchindexing.org. So the fact that you could browse to get the jnlp file shows that it is not a network issue. The issue must be with the Java version or some other problem.

Is this the first time you have run this program? I seem to remember a similar problem when I told the system to go offline. It wouldn't work correct after that. I had to delete the java web start cache to get the program to reload. It should also be noted that I was using Java 6 it may have even been a beta of Java 6 at the time. I have not used the indexing application for a while but I do remember those problems.

Jonathan

cannona wrote:Or perhaps an SSH Tunnel?

Aaron

Problem with SSH Tunnel is you need a target machine to tunnel through. Most people don't have that access.

thedqs wrote:Problem with SSH Tunnel is you need a target machine to tunnel through. Most people don't have that access.

True, although, I'm sure one of us, perhaps even me, could come up with something for the poster to use, if its just for a test. Anyway, the point is likely moot in light of previous posts.

Aaron

jkarras wrote:The CLOSE_WAIT state means that the close process has started. The first of the FIN flags have been sent. So actually the program has finished communicating. If a program was waiting for data netstat would not show this. It would just show ESTABLISHED. This you would have to look to the program for that kind of information not the TCP stack. If the program could not connect you would probably see the SYN_SENT stuck until the timer expires.

FYI my computer shows the same traceroute. It is a firewall blocking the echo requests. You can see the same things with other providers that like to do that.

It also should be noted that the IP you were tracerouting is http://www.familysearchindexing.org. So the fact that you could browse to get the jnlp file shows that it is not a network issue. The issue must be with the Java version or some other problem.

Is this the first time you have run this program? I seem to remember a similar problem when I told the system to go offline. It wouldn't work correct after that. I had to delete the java web start cache to get the program to reload. It should also be noted that I was using Java 6 it may have even been a beta of Java 6 at the time. I have not used the indexing application for a while but I do remember those problems.

Jonathan

Thanks for the explanations about TCP state and the identity of the IP address. I wonder whether there's a reason there is apparently no reverse DNS entry. (If there's not a reason for a lack of reverse DNS entry, maybe somebody should look into that.)

Freemind and the WmTest program mentioned earlier work fine. I tried WmTest with both Java 1.5.0_13 and 1.6, and it works fine with both. The Java 1.6 javaws viewer does have a problem, but the 1.5 viewer works fine.

My first attempt with the indexing application was with Java 1.5.0_09, and it didn't work. Since then, I installed Java 1.5.0_13 and 1.6.0_03. With Java 1.6, the indexing application puts up a second window, smaller and slightly darker background and entirely blank. With Java 1.5, it only puts up the one window. In both cases, the main application window GUI elements are dead in the water, and the main window is blank except for the top menu bar and the bottom status bar.

I have removed the directories and files created by the application (jobq.dat iArchives .java /tmp/iislock) several times just to get rid of any possible old dirt. There is never a difference in symptoms based on old file/directory removal (other than having to download the code).

Are there any other known things to check, odd ports that have to be open, etc.? If not, I guess I'll find out how the support folks handle odd cases.

Thanks for all the efforts to help.

rmrichesjr wrote: Are there any other known things to check, odd ports that have to be open, etc.? If not, I guess I'll find out how the support folks handle odd cases.

Thanks for all the efforts to help.

The JNLP file is just a text file that calls out the JARS and whatnot. You may look in it for more information.

rmrichesjr wrote:Thanks for the explanations about TCP state and the identity of the IP address. I wonder whether there's a reason there is apparently no reverse DNS entry. (If there's not a reason for a lack of reverse DNS entry, maybe somebody should look into that.)

Freemind and the WmTest program mentioned earlier work fine. I tried WmTest with both Java 1.5.0_13 and 1.6, and it works fine with both. The Java 1.6 javaws viewer does have a problem, but the 1.5 viewer works fine.

My first attempt with the indexing application was with Java 1.5.0_09, and it didn't work. Since then, I installed Java 1.5.0_13 and 1.6.0_03. With Java 1.6, the indexing application puts up a second window, smaller and slightly darker background and entirely blank. With Java 1.5, it only puts up the one window. In both cases, the main application window GUI elements are dead in the water, and the main window is blank except for the top menu bar and the bottom status bar.

I have removed the directories and files created by the application (jobq.dat iArchives .java /tmp/iislock) several times just to get rid of any possible old dirt. There is never a difference in symptoms based on old file/directory removal (other than having to download the code).

Are there any other known things to check, odd ports that have to be open, etc.? If not, I guess I'll find out how the support folks handle odd cases.

Thanks for all the efforts to help.

I know that Linux is not officially supported by the indexing project but I'll pass along the information anyway.

Tom

rmrichesjr wrote:I wonder whether there's a reason there is apparently no reverse DNS entry. (If there's not a reason for a lack of reverse DNS entry, maybe somebody should look into that.)

If you are talking about getting the DNS name from an IP you can only go so far. Some DNS servers will not release a name to a list. Others will. Windows' PING command has an option a that will do a basic DNS reverse lookup. Also I found this site http://www.zoneedit.com/lookup.html that will do forward and reverse lookups BUT it only gets the parent company that owns the IPs not any site web address.

Might this help, or am I off track with this one?

I've gotten listings of domains on a particular IP via this site. You first have to know the domain or IP address, including any that are listed as the nameserver domains.

http://whois.webhosting.info/

Does not always work, particularly in relation to some disreputable hosts, the kind that have been deliberately set up to host those that try to abuse the net or the email systems on it. But it works a good part of the time. You can plug in an IP or a domain name into the search box and get results a good majority of the time.

DNSStuff.com also has some interesting tools as well.

thedqs wrote:If you are talking about getting the DNS name from an IP you can only go so far. Some DNS servers will not release a name to a list. Others will. Windows' PING command has an option a that will do a basic DNS reverse lookup. Also I found this site http://www.zoneedit.com/lookup.html that will do forward and reverse lookups BUT it only gets the parent company that owns the IPs not any site web address.

JamesAnderson wrote:Might this help, or am I off track with this one?

I've gotten listings of domains on a particular IP via this site. You first have to know the domain or IP address, including any that are listed as the nameserver domains.

http://whois.webhosting.info/

Does not always work, particularly in relation to some disreputable hosts, the kind that have been deliberately set up to host those that try to abuse the net or the email systems on it. But it works a good part of the time. You can plug in an IP or a domain name into the search box and get results a good majority of the time.

DNSStuff.com also has some interesting tools as well.

The Linux 'host' command does forward or reverse DNS lookup, and it works on almost all IP addresses. The 'whois' command can at least get close on many others. Being as 'host' does reverse lookup of most IP addresses, I just found it a bit odd that this one had nothing.

Reverse DNS lookups ( nslookup ip.goes.here.) only work if the owner of the block of IP's has set them up. When setting up a forward DNS it does not automatically setup a reverse DNS. This depends on a few factors. Which DNS server software you use and if your DNS server answers authoritatively for those IP blocks. Most of the time the ISP or hosting provider owns the IPs and thus the reverse DNS must be modified by them.

In short forward DNS resolution doesn't mean there will be a corresponding reverse. A good example of this is the dyndns.org services. You could get thisisatest.homeip.com to point to your home computer on your cable connection. When doing a reverse lookup on said ip you will see something completely different. Comcast for example does the following c-98-202-38-142.hsd1.ut.comcast.net
this is quite common on connections of this type.

A previous poster mentioned using whois to find the owner of the IP. Whois will show the owner of the IP addresses or of domain names. Most of the time the owners of IP blocks are the ISP or hosting service which the service you are trying to access belongs to.

I just thought I would clarify the reason for no reverse DNS. Not to get the thread off topic.

Thanks for the info about reverse vs. forward DNS.

I think I stumbled upon the solution to the problem that was blocking me from indexing, the problem that the application window was blank except for the top menu bar and bottom status bar.

The "License Agreements' alias "FamilySearch? INDEXING PARTICIPATION AGREEMENT" window was coming up no more than 2 pixels on a side. I just happened to notice a fly-speck-looking blip that wouldn't go away. Resizing it to a decent size showed the agreement. Reading the legalese and clicking the buttons brought up some content into the application window.

Has anyone else had the agreement window come up only a pixel or two wide and tall? If so, let's file a bug report.

Nice find. I'd not seen that problem before but it could be that I've been on the program for a while and they may have changed the way the license page is displayed.

Tom

In case it might be of help if someone else sees the tiny window problem, I have a short C program I'll try to attach that seems to solve or at least work around the problem. I'm attaching it as a .txt, so rename it to xfixindexwindow.c before compiling.

For me (with Mandriva 2007.0, twm, no Gnome or KDE) the problem happens with a number of other pop-up-style windows, such as the lookup window that displays the authority list for given names and such. At present, the program must be started before doing whatever causes the tiny window to be created, but that would be easy to change if needed.

Nice work! For those who use it, let us know if you find any problems.

Tom

rmrichesjr wrote:In case it might be of help if someone else sees the tiny window problem, I have a short C program I'll try to attach that seems to solve or at least work around the problem. I'm attaching it as a .txt, so rename it to xfixindexwindow.c before compiling.

For me (with Mandriva 2007.0, twm, no Gnome or KDE) the problem happens with a number of other pop-up-style windows, such as the lookup window that displays the authority list for given names and such. At present, the program must be started before doing whatever causes the tiny window to be created, but that would be easy to change if needed.

tomw wrote:Nice work! For those who use it, let us know if you find any problems.

Tom

Okay. I found a problem. With the new release (2.5, IIRC) of the indexing application, the lookup list windows are no longer tiny, and the program's checks for a window being off-screen were broken. This update seems to work fairly well with the new application.

I'm using Ubuntu 8.04 "hardy heron" I've followed the instructions for installation of indexing software at the beginning of this thread. It installed nicely but whenever I try to open the program I get a message that says "A special update to the FamilySearch Indexing application has been completed. Start the application as you usually do." So I click on the icon again and the same message plays over, what could I do?

sorry for the double post but I also wanted to say that in Ubuntu "Hardy Heron", the sun javaws files are located at /usr/lib/jvm/java-6-sun-1.6.0.07/jre/javaws

That's no fun. I haven't run indexing lately, because I have been too busy with nFS and other things. In case you haven't already tried them, here are a few ideas:

Make sure your Java version is compatible with indexing. I think I have seen that the application is much more picky than I would think it ought to need to be about the Java version it runs on.

You might try moving your iArchives and/or .java directories out of the way. Unfortunately, that will lose some of your history with the indexing application.

If you get to a state where the indexing application appears hung, not responding to GUI command operations, you might check for off-screen windows. When I last did indexing, I had to run a separate program that scanned the window tree to find off-screen windows and move them on screen.

okay, I'll check, thank you!

Speaking of Ubuntu...
When I index and try to use the name lookup function, two odd things happen. First, lookup isn't in the menu that drops down when I click on the arrow next to the name field. So I use ctrl-f to bring up the lookup window. But the cursor won't go into any of the fields. I have to bring a different application up (any seems to do), then bring family indexing back up, and the cursor is now active in the name field.

Has any one else seen this, and better, found a cure?

Thanks

kafarnsworth

bobtheubuntuuser wrote:okay, I'll check, thank you!

Hi Bob,

I've just installed Indexing on Ubuntu 8.10 and 8.04 (different machines). They both suffered from the same problem you describe. Unfortunately, the links I could find on how to fix it were broken, so based on what information I could find I came up with this workaround (worked on both versions for me, your mileage may vary):

1. Change ownership of /etc/.java to your regular user ID. This is temporary. Something like "sudo chown -R bob:bob /etc/.java" for example.
2. Make sure you don't have any running java processes. In my case I had been trying several different things to get Indexing to load, and had a couple "stuck" java instances. Use "ps -ef | grep java" to look.
3. Start up Indexing. The "update" notice may appear once, but the program should successfully load.
4. Close Indexing.
5. Reset ownership of /etc/.java back to root: "sudo chown -R root:root /etc/.java".

For me, this worked on both machines. Good luck.

--Matt

What's /etc/.java? I haven't done indexing for several months, but all the files are around from when I did. I don't have a /etc/.java. On the other hand, my Java JRE/JDK is installed in /usr/local from Sun tarball rather than from the OS's package management system. I wonder if a /usr/local java installation and no /etc/.java might be a solution.

rmrichesjr wrote:What's /etc/.java? I haven't done indexing for several months, but all the files are around from when I did. I don't have a /etc/.java. On the other hand, my Java JRE/JDK is installed in /usr/local from Sun tarball rather than from the OS's package management system. I wonder if a /usr/local java installation and no /etc/.java might be a solution.

/etc/.java information, specifically related to Indexing, can be located here:
http://ph.ubuntuforums.com/showthread.php?t=900897

--Matt

There's a lot of good information in that thread--enough that I got lost partway through it.

I had one other thought on /etc/.java apparently needing to be writable by the indexing user. On my system, there's a $HOME/.java (where $HOME is the user's home directory) that is apparently used by indexing and perhaps other Java webstart stuff. Could it be that indexing or Java is getting confused about where it should be finding .java? If so, I suspect that might lead to a better solution.

jkarras wrote:From a command line run the following command. The link below came from the "Install Now" button on the front page of familysearchindexing.org.

Code:

javaws http://familysearchindexing.org/iis-apps/apps/iude.jnlp

In the future you can run the program with the following command line.

Code:

javaws -viewer

here is the result of running the "javaws http.... command above:

jack@ubuntu:~$ javaws -viewer
jack@ubuntu:~$ javaws http://familysearchindexing.org/iis-apps/apps/iude.jnlp
java.lang.NullPointerException
at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:192)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:609)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:302)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:134)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:191)
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:509)
at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:334)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)
netx: Initialization Error: Could not initialize applet. (net.sourceforge.jnlp.LaunchException Fatal: Initialization Error: A fatal error occurred while trying to verify jars.)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:519)
at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:334)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:308)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:134)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:191)
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:509)
... 2 more
Caused by:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:308)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:134)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:191)
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:509)
at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:334)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)

running javaws -viewer now says:
javasw: command not found

i am not understanding this at all.

please help. i can index in windows fine, but want to use Ubuntu 8.10 instead.

jbfriend43

I've seen many a nullpointer error in Java code (mostly in my own code during debug). It looks like the Java Network Launch Protocol (JNLP) is having some difficulty verifying the jars it thinks have been downloaded to run inside Java Web Start (JAVAWS). I did some indexing a year or two ago on a Mandriva Linux platform, but I never saw anything like that. It could be a bug in the indexing code base that is only tickled on Linux. Or, there could be a compatibility issue, with a potential workaround or not. Are you sure you're using a JDK installation that matches what the indexing site lists as a system requirement? If you only installed a JRE, you might try installing a full JDK to see if that might help. (JRE is Java Runtime Environment, and JDK is Java Development Kit.)

The last part, "javasw" vs. "javaws" is a simple typo. However, until the nullpointer problem is solved, fixing the typo isn't going to help.

If you do get it to come up but not respond to any UI events, you might try the program I think I posted a year or two ago that moves the indexing dialog windows onto the screen so you can see them. If you can't find the program, PM me.

here is the result of trying to run the following command.

jack@ubuntu:~$ javaws http://familysearchindexing.org/iis-apps/apps/iude.jnlp
java.lang.NullPointerException
at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:192)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:609)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:302)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:134)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:191)
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:509)
at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:334)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)
netx: Initialization Error: Could not initialize applet. (net.sourceforge.jnlp.LaunchException Fatal: Initialization Error: A fatal error occurred while trying to verify jars.)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:519)
at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:334)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:308)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:134)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:191)
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:509)
... 2 more
Caused by:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:308)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:134)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:191)
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:509)
at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:334)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)

jbfriend43 wrote:here is the result of trying to run the following command.

jack@ubuntu:~$ javaws http://familysearchindexing.org/iis-apps/apps/iude.jnlp
java.lang.NullPointerException
at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:192)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:609)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:302)
...

That's definitely a bad nullpointer. Unfortunately, I think most of the news I would have is bad news. With the stack that deep, it's very doubtful anyone from the outside will be able to do much with it. Last I heard, the official line from FamilySearch is they don't support Linux. You might report it and see if they'll take any action. The worst they can do is say they won't fix it.

One possible solution would be to run indexing from inside Wine (Wine Is Not an Emulator). I don't know whether that would work, but it might be worth trying. I doubt I'd be able to squeeze out enough time to do that experiment myself.

I use correctly familysearch indexing with my linux box:
1. Linux 2.6.28-15generic #49
2. Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux
3. java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu11)
OpenJDK Client VM (build 14.0-b08, mixed mode, sharing)

Hope this help.