| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
67926
|
Wed May 20 22:12:49 2015 |
 | David Pilgram | David.Pilgram@epost.org.uk | Bug report | Other | this one | Re: edit somebody else's draft | > this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
> methinks I should only be offered to edit draft messages that I own or I can edit. K.O.
I find it odd that I can see someone elses draft, but never one that I am in the middle of composing (using a
different tab of the browser) in the elog listing. There's one such draft Konstantin refers to in the logbook
listings now - last one was dark blue, this one a pink background, is there a reason for these different colours? |
|
67930
|
Fri May 22 13:50:31 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | this one | Re: edit somebody else's draft | > > this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
> > methinks I should only be offered to edit draft messages that I own or I can edit. K.O.
> I find it odd that I can see someone elses draft, but never one that I am in the middle of composing (using a
> different tab of the browser) in the elog listing. There's one such draft Konstantin refers to in the logbook
> listings now - last one was dark blue, this one a pink background, is there a reason for these different colours?
I just tried that on the "Demo" logbook and could see my own draft entry (which appears pink) in a second tab.
Dark blue means you have not updated the default.css file properly from the current distribution.
Stefan |
|
67974
|
Tue Jun 9 15:22:03 2015 |
| Midas User | stefan.ritt@psi.ch | Bug report | Other | this one | Re: edit somebody else's draft | > this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
> methinks I should only be offered to edit draft messages that I own or I can edit. K.O.
I changed this behaviour now, so authors can only edit their own drafts. Furthermore, drafts are not shown any more in the elog lists. In addition, deleting of entries is allowed now again in this forum, so if someone creates a draft by accident, he/she can delete it.
/Stefan |
|
67069
|
Fri May 20 22:45:00 2011 |
 | John M O'Donnell | odonnell@lanl.gov | Bug fix | Linux | svn 2414 | my_shell (OS_UNIX) uses /tmp/elog_shell - conflict when more than one elogd runs at the same time | all instances of elogd use the same file name in /tmp when calling my_shell. This can cause some inconsistent behavior when two or more copies of elogd are runnnig at the same time. (eg. one might detect ImageMagik is installed, and the other not,)
The propsed solution is to have the parent read from a pipe to the child rather from a file. A patch is attached. |
| Attachment 1: elogd.c.patch_shellPipe
|
--- elogd.c.orig 2011-05-20 13:28:48.000000000 -0600
+++ elogd.c 2011-05-20 14:16:12.000000000 -0600
@@ -866,25 +866,27 @@
#ifdef OS_UNIX
pid_t child_pid;
- int fh, status, i;
+ int fd[2], status, i;
char str[256];
+ /* create pipe for parent<->child communication */
+ if (pipe(fd) < 0)
+ return 0;
+
if ((child_pid = fork()) < 0)
return 0;
else if (child_pid > 0) {
- /* parent process waits for child */
- waitpid(child_pid, &status, 0);
+
+ /* parent does not write to child */
+ close(fd[1]);
/* read back result */
memset(result, 0, size);
- fh = open("/tmp/elog-shell", O_RDONLY);
- if (fh > 0) {
- i = read(fh, result, size);
- close(fh);
- }
+ i = read(fd[0], result, size);
+ close(fd[0]);
- /* remove temporary file */
- remove("/tmp/elog-shell");
+ /* parent process waits for child */
+ waitpid(child_pid, &status, 0);
/* strip trailing CR/LF */
while (strlen(result) > 0 && (result[strlen(result) - 1] == '\r' || result[strlen(result) - 1] == '\n'))
@@ -926,8 +928,7 @@
eprintf("Falling back to user \"%s\"\n", str);
}
- /* execute shell with redirection to /tmp/elog-shell */
- sprintf(str, "/bin/sh -c \"%s\" > /tmp/elog-shell 2>&1", cmd);
+ /* execute command with redirection to pipe to parent */
if (is_verbose()) {
efputs("Going to execute: ");
@@ -935,7 +936,17 @@
efputs("\n");
}
- system(str);
+ /* redirect stdout/stderr to pipe for parent to read */
+ close(STDOUT_FILENO); dup2(fd[1], STDOUT_FILENO);
+ close(STDERR_FILENO); dup2(fd[1], STDERR_FILENO);
+ /* child does not read the pipe */
+ close(fd[0]);
+ /* child nolonger uses fd[1] - use stderr or stdout instead */
+ close(fd[1]);
+
+ if (system(cmd) == -1) {
+ fprintf(stderr, "unable to execute command: %s\n", cmd);
+ }
_exit(0);
}
|
|
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
|
|
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. |
|
66830
|
Thu May 20 04:33:07 2010 |
| A. Martin | amartin@example.com | 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.
>
Thank you for your response.
I can certainly use another filename, but I'm curious why elog doesn't convert the filename "000000_000000_file.txt" to
"YYMMDD_HHMMSS_000000_000000_file.txt" when it gets uploaded. All other files are automatically prepended with this
string. Manually renaming the file and then editing the elog entry via text editor seems to fix the file.
thanks,
amartin |
|
66660
|
Wed Jan 6 22:17:49 2010 |
 | Aaron Couture | acouture@lanl.gov | Bug report | Linux | rev2280 | Problem with CRYPT+SSL and elog command line entries | I am in the process of setting up a new ELOG logbook. I checked out rev2280 from svn.savannah.psi.ch. I knew I wanted to encrypt passwords, so when I compiled, I used flags
USE_SSL=1
and
USE_CRYPT=1
I am running Red Hat enterprise linux 3, glibc-devel-2.3.2-95.50, openssl-devel-0.9.7a-33.25
Everything seemed to be working fine--I was able to set up logbooks using both a password file as well as write passwords and make entries to the logs. Then I tried to use the command line 'elog' to make an entry which failed to both logbooks.
/opt/elog/pro/elogd -c /opt/elog/pro/dansce_fancy.cfg -l Demo1 -w <mypassword>
Would change the password in dansce_fancy.cfg and I could make entries through the web interface, but
elog -h acouture -s -p 8081 -w <mypassword> -l Demo1 -a Author="Aaron Couture" -a Type=Routine -m Sampleinfo.txt -x -n 1
failed with
Error: Invalid user name or password
I got the same behaviour when I used a logbook with a user/password pair defined in a password file.
When I looked at the output from running elogd with the -v flag, I could see that everything was being received on the server side, but that the password did not agree with the write password in dansce_fancy.cfg
I then recompiled elog with
USE_SSL=1
USE_CRYPT=
And then the elog command line entries worked, both with write passwords and a password file (after recreating the password file and the write password). Looking at the elog.c source code, it appears that it does not know to use crypt rather then base64_encode when USE_CRYPT is true. elogd.c defined different behaviour if USE_CRYPT is defined.
Thanks,
Aaron Couture
|
|