| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
66813
|
Sun May 9 18:12:28 2010 |
 | John Rouillard | rouilj+elog@cs.umb.edu | Bug report | Linux | Other | 2.7.8 | 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 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | Other | 2.7.8 | 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 |
|
66822
|
Sat May 15 06:01:40 2010 |
 | A. Martin | amartin@example.com | Bug report | All | svn | attachment filename bug & Makefile issue |
If I upload the file "000000_000000_file.txt", elog will chop the filename to "file.txt." Also, this effects
the file's displayed "Uploaded" time. It shows the file as being uploaded on: "Tue Nov 30 00:00:00 1999"
Note the attachment to this post.
----
Makefile has the line:
# flag for SSL support
USE_SSL = 1
However setting USE_SSL = 0 does not prevent the openssl libraries from being used. Same issue with USE_CRYPT.
You have to comment them out.
Lines 76-85 of Makefile should be replaced with this:
ifdef USE_SSL
ifneq ($(USE_SSL), 0)
CFLAGS += -DHAVE_SSL
LIBS += -lssl
endif
endif
ifdef USE_CRYPT
ifneq ($(USE_CRYPT), 0)
CFLAGS += -DHAVE_CRYPT
LIBS += -lcrypt
endif
endif
Thanks,
amartin |
| Attachment 1: file.txt
|
|
66823
|
Mon May 17 04:01:16 2010 |
| John Rouillard | rouilj+elog@cs.umb.edu | Bug report | Linux | Other | 2.7.8 | 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
....
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
|
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 |
| John Rouillard | rouilj+elog@cs.umb.edu | Bug report | Linux | Other | 2.7.8 | 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;
}
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.
|
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 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | Other | 2.7.8 | Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message |
| John Rouillard wrote: |
| 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;
}
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.
|
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. |
|
66826
|
Tue May 18 16:40:15 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | svn | Re: attachment filename bug & Makefile issue | > If I upload the file "000000_000000_file.txt", elog will chop the filename to "file.txt." Also, this effects
> the file's displayed "Uploaded" time. It shows the file as being uploaded on: "Tue Nov 30 00:00:00 1999"
Arghh! Why did you choose such a filename? This is the ELOG internal file format, which is YYMMDD_HHMMSS_name.ext.
For internal reasons (mainly for synchronization) the system checks every file name, and if it contains 6 numbers
followed by a "_" followed by 6 other numbers it thinks it's a valid date/time and uses that. Your time is however
0.0.0000, that's why it gets converted to some date in 1999. Do you absolutely need this functionality? While I can
easily remove the interpretation of the date, it would break the synchronization functionality and I would have to
find some other method to pass the file date/time, which would be quite some work. So if it's not too important for
you, I would like to keep it as it is.
> Makefile has the line:
>
> # flag for SSL support
> USE_SSL = 1
>
> However setting USE_SSL = 0 does not prevent the openssl libraries from being used. Same issue with USE_CRYPT.
> You have to comment them out.
>
> Lines 76-85 of Makefile should be replaced with this:
>
> ifdef USE_SSL
> ifneq ($(USE_SSL), 0)
> CFLAGS += -DHAVE_SSL
> LIBS += -lssl
> endif
> endif
>
> ifdef USE_CRYPT
> ifneq ($(USE_CRYPT), 0)
> CFLAGS += -DHAVE_CRYPT
> LIBS += -lcrypt
> endif
> endif
The original idea was that one outcomments the whole line, like
#USE_SSL = 1
which always worked, but I agree that your solution is more general, so I changed the official Makefile. Thanks for
that. |
|
66827
|
Tue May 18 21:17:35 2010 |
| John Rouillard | rouilj+elog@cs.umb.edu | Bug report | Linux | Other | 2.7.8 | Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message |
| Stefan Ritt wrote: |
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. |
Yup. My settings are:
Guest menu commands = List, Last 10, Find, Login, Help
Guest List Menu commands = List, Last 10, Find, Login, Help
Ok, so this patch fixes the problem on the client side (rather than the server side like my patch) of the
cloning process. I can't tell from the patch above but will this fix allow the cloning process to "complete"
but without the password file being copied, or does code outside the patched section try to login and get
the password file?
-- rouilj |
|