Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 189 of 801  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Show attachments  Show only new entries    6408 Entries 
Goto page Previous  1, 2, 3 ... 188, 189, 190 ... 799, 800, 801   Next  
ID Date Icon Author Author Email Category OS ELOG Version Subject
  68271   Fri Feb 26 18:11:14 2016 Reply Devin Bougiedevin.bougie@cornell.eduBug reportLinux3.1.1Re: Links to images in notification message

From the notification I received, it looks like "2" is a problem with this server.  In the email notification, we would like images to be a link to a URL displaying the full-size image (as they are in v2.9.2).

Thanks,

Devin

  68270   Fri Feb 26 17:35:54 2016 Entry Juergen Diefenbachdiefenba@uni-mainz.deBug reportLinux3.1.1Execute new|edit doesn't seem to work
I am trying to use the "Execute new|edit|delete" feature to track changes to an elog using git.

When a new entry is created a shell script should be executed (certain attributes of the logbook entry should be passed as arguments to it). The script will then automatically stage all changes and create an appropriate git commit message. For a "new" entry in the logbook the commit message is a bit more verbose. When editing or deleting a message only a short commit message like "Edit message 25" should be created. Therefore I really need to distinguish between "new", "edit", and "delete".

However, I experienced unreproducible behavior when creating "new" entries. Sometimes the command specified by "Execute new=" is called, sometimes the one specified by "Execute edit=" is executed. Most of the time it doesn't work as expected. Frown

What I did so far to understand what goes wrong is I looked into elogd.c and found in
void submit_elog(LOGBOOK * lbs)
that bedit is sometimes true and sometimes false, when creating a new entry, although it should be false then (right?).
This is why elogd then sometimes retrieves the wrong shell command from getcfg(lbs->name, "Execute edit"...) instead of getcfg(lbs->name, "Execute new"...) around line 23610 (not exact due to some eprintf()s inserted here and there to look at bedit and so on).

When deleting an entry, everything works fine: the shell command defined via "Execute delete=" is run, but this happens somewhere else in the code so it's not a surprise.

Do you have an idea how to fix this or can you point me in some direction to further track it down? Thank you!
  68269   Fri Feb 26 17:20:52 2016 Question Devin Bougiedevin.bougie@cornell.eduBug reportLinux3.1.1Links to images in notification message

We see two problems with the notificaiton email when attaching an image inline using drag-and-drop.

  1. The thumbnail does not appear in its proper location inline.  There is a ? placeholder where the thumbnail should be, and the thumbnail then appears at the end of the message.
  2. Neither the ? placeholder nor the thumbnail that do appear are clickable.

Our v2.9.2 test installation exhibits the desired behavior.  

  1. The thumbnail appears in its correct location inline.
  2. If you click on the thumbnail, you arrive at a URL displaying the full size image.

I am not able to drag-and-drop into the body of this message to test the behavior here.  I am attaching  a screenshot showing an example of the problem from our server.

Any suggestions would be greatly appreciated.

Many thanks,

Devin

 

 

 

 

  68268   Fri Feb 26 09:09:03 2016 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux3.1.1-1Re: 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++)
       ^~~

 

  68267   Fri Feb 26 08:47:22 2016 Warning Nigel Warrwarr@ikp.uni-koeln.deBug reportLinux3.1.1-1Possible bug in elogd execute_shell

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++)
       ^~~

  Draft   Fri Feb 26 08:38:06 2016  Nigel Warrwarr@ikp.uni-koeln.deBug reportLinux Possible bug in elogd execute_shell

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++)
       ^~~

  68265   Wed Feb 24 09:48:09 2016 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.0.0Re: Kerberos auth not available on 3.0 ?

Hi Jimmy, no Kerberos is not compiled into the Windows installer. You are the first one asking for that under Windows. All other Kerberos users use Linux so far. You have to compile the Windows version yourelf. This is because there are several versions of Kerberos around and people need differnt libraries. Sorry for that.

/Stefan

Jimmy Bria wrote:

Hi Stefan - Do you know is Kerberos is available (compiled) on the Windows installer?

-Jimmy

Stefan Ritt wrote:

Kerberos support is not compiled into the binary RPM. You have to comile from sources to get that. The reason is that there are different Kerberos libraries around, and different people need different ones.

/Stefan

 

 

 

  68264   Tue Feb 23 22:32:30 2016 Reply Jimmy Briajimmy.bria@gmail.comQuestionLinux3.0.0Re: Kerberos auth not available on 3.0 ?

Hi Stefan - Do you know is Kerberos is available (compiled) on the Windows installer?

-Jimmy

Stefan Ritt wrote:

Kerberos support is not compiled into the binary RPM. You have to comile from sources to get that. The reason is that there are different Kerberos libraries around, and different people need different ones.

/Stefan

 

 

Goto page Previous  1, 2, 3 ... 188, 189, 190 ... 799, 800, 801   Next  
ELOG V3.1.5-3fb85fa6