| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68268
|
Fri Feb 26 09:09:03 2016 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.1-1 | Re: Possible bug in elogd execute_shell |
Absolutely correct! Nice to see compilers getting better and better. I changed the code and committed it.
| Nigel Warr wrote: |
|
I was just playing around with gcc6's new feature for warning about misleading indentation (which can often hide real bugs) and I think it found one in elog-3.1.1-1 at src/elogd.c:22538. Here there is an if statement, which looks as though it should be inside a loop, but it isn't. The code is:
for (i = 0; i < MAX_ATTACHMENTS; i++)
generate_subdir_name(att_file[i], subdir, sizeof(subdir));
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strl$
< sizeof(shell_cmd) + 1) {
strcpy(p, "\"");
strcat(p, lbs->data_dir);
strlcat(str, subdir, sizeof(str));
strlcpy(str, att_file[i], sizeof(str));
str_escape(str, sizeof(str));
strcat(p, str);
strcat(p, "\" ");
p += strlen(p);
}
and the if statment is accessing the loop variable i but it is actually outside the loop. Presumably, there should be some more curly brackets here. gcc6 gave the warning:
src/elogd.c: In function ‘execute_shell’:
src/elogd.c:22538:10: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strlen(subdir) + strlen(att_file[i])
^~
src/elogd.c:22536:7: note: ...this ‘for’ clause, but it is not
for (i = 0; i < MAX_ATTACHMENTS; i++)
^~~
|
|
|
68358
|
Tue Jul 12 21:23:13 2016 |
 | Austin Reid | arreid3@ncsu.edu | Bug report | Other | 3.1.1- | Email report has incorrect pictures |
My group uses the precompiled Debian binary, and I use ELCode to format my log reports. (I've found it to be the easiest way to generate inline images)
Yesterday, I submitted an entry that renders correctly on the elog itself, but the email report that was sent to my collaborators was quite confusing, because every picture in it was the same. Interestingly, all the images used inline in the report were attached to the original, but they were stripped of their context.
I've attached screen shots of both reports. |
| Attachment 1: emailedversion.jpg
|
|
| Attachment 2: okversion.jpg
|
|
|
68919
|
Mon Mar 25 12:31:34 2019 |
 | gibelin julien | gibelin@unicaen.fr | Question | Linux | 3.1.1 revision | elog client through proxy |
Dear users,
we started an elog serveur (using ssl) and open to the world which is working fine.
However I am trying to access it via the command line client, from a computer that uses a proxy to connect to internet.
The environnment variable are set :
declare -x ftp_proxy="ftp://myproxy:3128/"
declare -x http_proxy="http://myproxy:3128/"
declare -x https_proxy="https://myproxy:3128/"
declare -x socks_proxy="socks://myproxy:3128/"
but when I try to connect
elog -h myelog -p 443 -l lognote -s 1 -u username passwd -w last
I have the following message :
Cannot connect to host myelog, port 44
How should I proceed ?
Best regards
JG
:
|
|
68923
|
Thu Apr 4 11:57:46 2019 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.1 revision | Re: elog client through proxy |
The "elog" client does unfortunately not support proxies. You could however achieve the same with the "curl" tool. Have a look at elog:68597
Stefan
| gibelin julien wrote: |
|
Dear users,
we started an elog serveur (using ssl) and open to the world which is working fine.
However I am trying to access it via the command line client, from a computer that uses a proxy to connect to internet.
The environnment variable are set :
declare -x ftp_proxy="ftp://myproxy:3128/"
declare -x http_proxy="http://myproxy:3128/"
declare -x https_proxy="https://myproxy:3128/"
declare -x socks_proxy="socks://myproxy:3128/"
but when I try to connect
elog -h myelog -p 443 -l lognote -s 1 -u username passwd -w last
I have the following message :
Cannot connect to host myelog, port 44
How should I proceed ?
Best regards
JG
:
|
|
|
68070
|
Tue Aug 4 15:35:39 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | All | 3.1.1 | Version 3.1.1 of elog has been released |
Version 3.1.1, released August 4th, 2015
-
Updated CKEditor to version 4.5.1
-
Implemented "Date/Time format <attribute> = ..."
-
Implemented "Use Email Subject Edit = ..."
-
Replaced "Back" by "Delete" button
-
Fixed many issues with Draft Messages
-
CSS file is now in *addition* to the default file elog.css
-
Added LDAP documentation
-
Added "Logout to URL = ..." option
-
Added description of Apacher server authentication
|
|
68078
|
Wed Aug 12 16:59:30 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Isolating search urls |
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip |
|
68079
|
Wed Aug 12 17:19:45 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls |
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
Draft
|
Thu Aug 13 10:05:22 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls |
Thanks for the quick response!
The idea is to run multiple instances of elog where
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|