ELOG Forum

Re: elogd 2.6.1 program Crash is repeatable under Windows

All

2.6.1-1668

Stefan Ritt wrote:

Steve Jones wrote:

BTW, Stefan, unless you can make the most recent version of a Windows eLog available I cannot test the most recent -- I do not have access to a Windows development environment. Solaris-Yes, Linux-Yes, Windoze-No.

There is a 2.6.1-4 version for Windows for download, which contains the most recent code.

Quote:

Ok, I loaded the new Windows version ELOG V2.6.1-1681. The new version has the same behavior and it is entirely related to Top Group. With a simple Top Group setup things appear to work fine until one attempts to either create or delete a new logbook. There are other quirky things - I don't think Top Group is ready for really complex setups. In fact, this URL that is constructed by elog (http://localhost:8080/Engineering%20Compute%20Change%20Logs/Test/?cmd=Config) will cause elog to coredump but only with a very complex configfile. If I simply remove the "Top" from the "Group" directive I get the expected message "Error: logbook "Engineering Compute Change Logs" not defined in elogd.cfg
Please use your browser's back button to go back".

Another interesting point of reference - I went back to 2.5.9-4 (windows) and get the same behavior.

Now, making things really simple I added Top Group support to the demo that comes with the Windows install. This configfile:

[global]
port = 8080

Show top groups = 1
Top Group Demo Groups = demo, test7

[global Demo Groups]
Theme = default
Comment = General linux tips & tricks
Attributes = Author, Type, Category, Subject
Options Type = Routine, Software Installation, Problem Fixed, Configuration, Other
Options Category = General, Hardware, Software, Network, Other
Extendable Options = Category
Required Attributes = Author, Type
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type

[demo]

results in this redisplay after a new logbook create I have included in an attached screenshot. Please note that everything is generally not correct. So, even though eLog does not crash with this simple config it does support my observation that as I render the congfile more complex I corrupt eLog more until it finally crashes. Stefan, I would be interested in seeing how the above config runs on one of your windows systems.

Attachment 1: elog_2.JPG

66813

Sun May 9 18:12:28 2010

Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

Does anybody have any ideas? Should I post a config or something?

-- rouilj

66814

Mon May 10 09:55:12 2010

Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

Hi Rouilj,

re-posting your bug report doe not help. If I'm not replying immediately it means I'm pretty busy with other things, so just be patient.

Your problem is related to the reply from the server you posted. After you send

GET /Discussion/?cmd=GetPwdFile

you should get the login page, which starts with

HTTP/1.1 200 Document follows
....
<title>ELOG Login</title>
....

but you do get

HTTP/1.1 404 Not Found
....

The best thing to diagnose this problem is to run the server with the "-v" flag, so you don't have to run truss. Then compare the request sent by your cloning process (your GET /Discussion/?cmd=GetPwdFiel from above) and compare it if you send from your browser

http://host.example.org:8080/Discussion/?cmd=GetPwdFile

now without sending any cookies. Maybe you can figure out why the server replies with a 404 instead of a 200 when run from the cloning process. Try a very simple elogd.cfg on your sever side, just the basic thing with a "Password file = ..." setting. Do you have any blanks in your logbook name? Are you using Apache as a proxy?

Anyhow, if this does not work for you, just copy your password file manually as you did already. The rest should then work fine for you.

- Stefan

66823

Mon May 17 04:01:16 2010

Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

Stefan Ritt wrote:

Hi Rouilj,
re-posting your bug report doe not help. If I'm not replying immediately it means I'm pretty busy with other things, so just be patient.

Fair enough. I just saw posts after mine being responded to and I wasn't sure if my choice of icon
was causing it to be filtered out or not.

Stefan Ritt wrote:

Your problem is related to the reply from the server you posted. After you send

GET /Discussion/?cmd=GetPwdFile

you should get the login page, which starts with

HTTP/1.1 200 Document follows
....
<title>ELOG Login</title>
....

but you do get

HTTP/1.1 404 Not Found
....

Using the url above from mozilla without being logged into the elogd server, elogd -v shows:

GET /Discussion/?cmd=GetPwdFile HTTP/1.1
Host: rouilj.dyndns.org:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: elmode=Summary; urem=1


==== Return ================================
HTTP/1.1 404 Not Found
Server: ELOG HTTP 2.7.8-2278
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 665


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<title>ELOG error</title>
<link rel="stylesheet" type="text/css" href="default.css">
</head>
<body><center>
<table class="dlgframe" width="50%" cellpadding="1" cellspacing="0"<tr><td class="errormsg">Error: Command "<b>GetPwdFile</b>" not allowed</td></tr>
<tr><td class="errormsg"><script language="javascript" type="text/javascript">
document.write("<button type=button onClick=history.back()>Back</button>"); 
</script>
<noscript>
Please use your browser's back button to go back
</noscript>
</td></tr>
</table>
</center></body></html>

It looks like it's not redirecting to the login page and returning a 404 instead.
If I log in and submit the same URL, it displays the password file as expected.

I think I kind of see what's happening here. In is_command_allowed you add the GetPwdFile to the list of
allowed command but only if is_admin_user is true. Since the user is guest at that point, I assume
is_admin_user returns false making is_command_allowed return false. Then the redirect is attempted by this
code sequence:

  if (!is_command_allowed(lbs, command)) {
      /* redirect to login page for new command */
      if (strieq(command, loc("New")) && !isparam("unm")) {
         check_user_password(lbs, "", "", _cmdline);
         return;
      }

but to me that looks like it will execute only if the command contains the word new
(or it's translated equivalent if I understand loc() properly)?? Since the command string
GetPwdFile doesn't match no login screen is presented by check_user_password.

Stefan Ritt wrote:

now without sending any cookies. Maybe you can figure out why the server replies with a 404 instead of a 200 when run from the cloning process. Try a very simple elogd.cfg on your sever side, just the basic thing with a "Password file = ..." setting. Do you have any blanks in your logbook name? Are you using Apache as a proxy?

Anyhow, if this does not work for you, just copy your password file manually as you did already. The rest should then work fine for you.

- Stefan

No apache in the mix (although I may be adding it in the future), no blanks in the
logbook names.

-- rouilj

66824

Mon May 17 04:19:29 2010

Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

John Rouillard wrote:

I think I kind of see what's happening here. In is_command_allowed you add the GetPwdFile to the list of
allowed command but only if is_admin_user is true. Since the user is guest at that point, I assume
is_admin_user returns false making is_command_allowed return false. Then the redirect is attempted by this
code sequence:

  if (!is_command_allowed(lbs, command)) {
      /* redirect to login page for new command */
      if (strieq(command, loc("New")) && !isparam("unm")) {
         check_user_password(lbs, "", "", _cmdline);
         return;
      }

The attached patch (also included inline) seems to fix the problem. I am sure it can be done more cleanly but...

--- elogd.c~    2009-12-02 05:53:44.000000000 -0500
+++ elogd.c     2010-05-16 21:58:14.000000000 -0400
@@ -26236,6 +26236,10 @@
          check_user_password(lbs, "", "", _cmdline);
          return;
       }
+      if (strieq(command, loc("GetPwdFile")) && !isparam("unm")) {
+         check_user_password(lbs, "", "", _cmdline);
+         return;
+      }
 
       strencode2(str2, command, sizeof(str3));
       sprintf(str, loc("Error: Command \"<b>%s</b>\" not allowed"), str2);

-- rouilj

Attachment 1: elog_GetPwdFile_diff.patch

--- elogd.c~	2009-12-02 05:53:44.000000000 -0500
+++ elogd.c	2010-05-16 21:58:14.000000000 -0400
@@ -26236,6 +26236,10 @@
          check_user_password(lbs, "", "", _cmdline);
          return;
       }
+      if (strieq(command, loc("GetPwdFile")) && !isparam("unm")) {
+         check_user_password(lbs, "", "", _cmdline);
+         return;
+      }
 
       strencode2(str2, command, sizeof(str3));
       sprintf(str, loc("Error: Command \"<b>%s</b>\" not allowed"), str2);

66825

Tue May 18 13:21:32 2010

Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

John Rouillard wrote:

  if (!is_command_allowed(lbs, command)) {
      /* redirect to login page for new command */
      if (strieq(command, loc("New")) && !isparam("unm")) {
         check_user_password(lbs, "", "", _cmdline);
         return;
      }

The attached patch (also included inline) seems to fix the problem. I am sure it can be done more cleanly but...

--- elogd.c~    2009-12-02 05:53:44.000000000 -0500
+++ elogd.c     2010-05-16 21:58:14.000000000 -0400
@@ -26236,6 +26236,10 @@
          check_user_password(lbs, "", "", _cmdline);
          return;
       }
+      if (strieq(command, loc("GetPwdFile")) && !isparam("unm")) {
+         check_user_password(lbs, "", "", _cmdline);
+         return;
+      }
 
       strencode2(str2, command, sizeof(str3));
       sprintf(str, loc("Error: Command \"<b>%s</b>\" not allowed"), str2);

-- rouilj

Ok, now I got it! The problem was that you used "Guest menu commands = ..." and I did not. So the behavior is different with that option, which is why I could not reproduce your problem initially. Now I could reproduce it and the cleanest fix is this:

--- elogd.c     (revision 2294)
+++ elogd.c     (working copy)
@@ -15704,7 +15704,7 @@
          fgets(pwd, sizeof(pwd), stdin);
          while (pwd[strlen(pwd) - 1] == '\n' || pwd[strlen(pwd) - 1] == '\r')
             pwd[strlen(pwd) - 1] = 0;
-      } else if (status != 200 && status != 302) {
+      } else if (status != 200 && status != 302 && status != 404) {
          xfree(buffer);
          *strchr(str, '?') = 0;

which is just accept the 404 response and not abort the cloning process.

66827

Tue May 18 21:17:35 2010