ssh -L 1234:your.server.name:8080 your.firewall.name
firefox http://localhost:1234/

http://your.server.name:8080/logbookname/080207_101110/Picture.jpg

http://localhost:1234/logbookname/080207_101110/Picture.jpg

Thank you for the quick support!

From your point of view that request is reasonable, but the reason of having mxml in a separate top level directory is that I use it in many different projects. If I would keep a copy of mxml in each project, I would have to update all of them manually if there is a bug. On the other hand the code of mxml changes very seldom. If you look at the history, it got ~5 changes last year, while elog itself had hundreds. And since I do not change the API, a bugfix in mxml should be to the benefit of all elog versions. It is like with other projects which depend on a number of packages. Like if you install Apache for example, you need a certain version of OpenSLL, a certain version of libcrypt, and so on.  So think of mxml like another package you have to combine with elog.

Hi

I tried the 'Preset ticket = TCK-#####' method to create unique numbers for our application. This worked very nicely until we replied to a earlier message, if we then create a new message the system creates a sequential number after the last message number we replied to. For example if we have 10 messages. If someone replies to message number #2 then when a new record is created it is then assigned number #3 not #11, thus making a duplicate entry for #3.

 Any ideas?

Cheers Richard

The error is produced by the C routine "gethostbyname". This routine tries to obtain the IP address of your host max13 and fails. The error "no error" is the error passed to elog from the underlying operating system, so please blame Windows for that. I guess you have a problem that on the machine you get the error you have some DNS problem, so this machine does not know max13. Try to "ping" max13 or do a "nslookup max13" to verify this. Maybe you have to add your domain after max13, or put this machine explicitly into \Windows\System32\drivers\etc\hosts.

I added some version information being displayed with the "-?" option. This feature will be contained in the next release.

Feb 15 17:11:05 iadopsutil04p elogd[23761]: elogd 2.7.2 built Feb 14 2008, 20:55:38 
Feb 15 17:11:05 iadopsutil04p elogd[23761]: revision 2041
Feb 15 17:11:05 iadopsutil04p elogd[23761]: FCKedit detected
Feb 15 17:11:05 iadopsutil04p elogd[23763]: Cannot restore original GID/UID.
Feb 15 17:11:05 iadopsutil04p elogd[23763]: Cannot remove pidfile "/var/run/elogd.pid" ; Permission denied
Feb 15 17:11:05 iadopsutil04p elogd[23761]: Server listening on port 80 ...

The error message above come from the PID file /var/run/elogd.pid which cannot be removed. This file is only for information purpose, to tell any script which PID the elogd daemon has. If one elogd crashed in the past, the file might still be there although the program is not running, causing some error to show up, but which can normally be ignored.

The fact that elogd stays for about 30 seconds can only be contributed to the fact that you have very large logbooks, which are scanned during startup. You can check this by starting elogd interactively with the "-v" option. Then you will see the scanning process. The next thing is if you really get a crash, you can produce a core dump, so it can be analyzed to figure out where elogd has crashed. To my knowledge the only way you can do that is by having some logbooks with invalid data. Can you try your set-up with empty logbooks?

- Stefan

Stefan:

Thanks for the analysis and information.  Why am I not surprised that the "No error" came from Windows!? 

I tried some of your suggestions with the following results:

1.  Ping ==>= works as expected on the failing machine; that is, can successfully ping "max13"  I also can ping successfully in the reverse direction; that is, from "max13" to my "client" machine.

2.  NSLookUp ==>does not work on any of the 3 machines.

3.  Added the computer name "max13" to HOSTS file; ==> observed no change in behavior (i.e., still fails)

I did notice that on the 2 machines that function as desired that there is no anti-virus software installed, while on the non-funcational machine there is A-V SW installed.  I am able to bring up eLOG via the browser on the non-functional machine, so am unsure if the A-V SW is a factor; that is, why does ELOG via browser work as expected, but not via command line. 

QUESTION:  does command line ELOG connect differently than ELOG through the browser?

I ask this question for perhaps the A-V SW *is* blocking some port or whatever, and I will need to ask our IT department how to remove such a restriction.

ELOG connects in the same way as the browser, but it is a different program. I have seen some firewalls which explicitly exclude browsers in firewall rules. So it might well be that yours blocks ELOG but not your browser. So give it a try and disable it.

Since both my machine and the Elog server PC are inside my company's "security zone", I am not running a firewall on my machine.

For what it's worth:  in trying to research the "No error" message, I did come across this information on MS's website; that is, their statement is:

The gethostbyname function retrieves host information corresponding to a host name from a host database.

Note  The gethostbyname function has been deprecated by the introduction of the getaddrinfo function. Developers creating Windows Sockets 2 applications are urged to use the getaddrinfo function instead of gethostbyname.

SOURCE:  http://msdn2.microsoft.com/en-us/library/ms738524.aspx