Re: Subst variables and Execute, posted by soren poulsen on Thu Jul 29 13:45:47 2010
|
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
There is sometimes a problem with substitutions like "Execute delete = echo $message id".
It seems the problem is that if you delete a logbook entry that is not created with the current logbook attributes, the substitution variables are replaced with the variable name, and not the variable value.
In this example, according to the log file it becomes SHELL "message id" instead of SHELL "234", if the logbook entry is 234.
Soren
|
I tried to reproduce it, but it always worked for me. So I need a step-by-step instruction from you on how to reproduce the problem, ideally starting from the demo logbook from the distribution. Only if I can reproduce the problem, I will be able to fix it.
|
It is of course my job to reproduce it (and explain how-to). Thanks for your consideration. |
|
Re: Important security update of ELOG, posted by Stefan Ritt on Thu Aug 5 12:26:12 2010
|
| Stefan Ritt wrote: |
|
Dear ELOG users,
this is to announce an important security update. As proposed by Lukasz Olejnik (CERN/PSNC), ELOG has now switched to strong encryption of password. So everybody concerned in security is advised to update to the new version 2.8.0. Existing password files for Windows users and Linux users not using HAVE_CRYPT are automatically converted. Those installations which used HAVE_CRYPT in the past under Linux have to ask their users to re-enter their password (via the link "Forgot password") after the upgrade to version 2.8.0.
Best regards,
Stefan Ritt
|
I just realized that the command line elog utility did not yet use the new encryption. So automatic elog submissions using passwords are broken in version 2.8.0. I made an intermediate version 2.8.0-2 which fixes that. However you only need to update it if you use the elog utility and have problems with the 2.8.0 version. |
|
Re: elog keeps recreating preview .png files?, posted by Stefan Ritt on Fri Aug 6 12:55:08 2010
|
| Kontantin Olchanski wrote: |
|
Hi, I rsync an elog database from CERN to TRIUMF every few months and I notice that rsync keeps copying preview files (xxx.png.png, xxx.gif.png, etc) from very old entries. I guess that elogd creates these files from scratch each time they are needed, overwriting any previously existing preview files. This creates extra rsync network traffic and rsync takes longer to complete. Is there any way to avoid this? K.O.
|
Actually the thumbnail files are only created if they are not there. This is done in the function crate_thumbnail():
i = get_thumb_name(file_name, str, sizeof(str), 0);
if (i)
return i;
So if these files are recreated always, something must be wrong there. Or you sysadmin runs a cron job which deletes them every evening  |
|
Re: Error Message in "Demo of database-like elog", posted by Robert Heine on Thu Aug 26 11:27:08 2010
|
| Stefan Ritt wrote: |
|
| mike cianci wrote: |
|
I attempted to remove the text editor (like you did in "Demo of database-like elog") using "Show text = 0".
In both your Demo and my logbook when you hit "New" - Explorer generates the folowing error message
Error: The Textarea with id or name set to "text" was not found.
Is there a solution or do we just live with it.
Thanks, Mike
|
Thanks for reporting that bug. I fixed it in SVN revision 2188, and the fix will be contained in the next release.
|
I am getting the same message in the current version (V2.8.0-2312), if the "Preset text" text body contains the equal sign '='. Then this message pops up and the HTML-editor dosn't show its menu bars, with the elog- or plain text editor this does not happen. It happens as well with firefox as with internet explorer.
best regards
Robert |
|
Re: How to make Subst run?, posted by Andreas Luedeke on Fri Sep 3 14:14:07 2010
|
| Robert Heine wrote: | Dear colleagues,
I tried to get an Subst <attrib> = $shell(<command>) to work and put this into a Preset text line, like e.g.:
Attributes = subject, ...
Options <name> = test{1}, ...
Subst myvar = $shell(dir)
{1} Preset subject = Test
{1} Preset text = $myvar
Which results in an ELOG-entry having printed "$myvar" in its body instead of the expected substitution. Changing the Subst command to: "Subst myvar = $host" or even to "Subst myvar = Test" also resulted in printing just the string "$myvar" into the submitted Elog-entry. - What am I doing wrong? |
What you want to do is done simply by:{1} Preset text = $shell(dir)You expect "Subst" to create new variables, but it cannot do this.
"Subst" can overwrite the value of an existing field in an already submitted entry, while
"Preset" allows to prefill an existing entry field and the user may overwrites it before submitting (if it is not "Locked".)
In both cases you can either call a shellscript to create the desired text, or you can use
one of the predefined variables defined in the help pages "ELOG - Syntax of elogd.cfg" for "Subst".
Cheers Andreas |
|
Re: Elog v2.7.8 does not show substituted attributes while editing or replying, posted by Andreas Luedeke on Fri Sep 3 14:25:37 2010
|
| Dennis Seitz wrote: |
|
Since we updated to 2.7.8 we've found a problem.
Previously, when we used
Subst on reply subject = Re: $subject
The new "Re: " text would appear in the "subject" field while the user was editing their reply, and they could edit or delete it.
Since 2.7.8, however, it does not appear while editing, but shows up only after the user submits their entry. We would prefer that this appears while the user is editing, because in some cases we want the users to have the option to modify this text. Was this intentional? Is there a way to restore the previous functionality?[...]
|
Sorry, that appears to be an undocumented bug fix :-)
The desired behaviour should be created by
Preset on reply subject = Re: $subject
The command "Subst" is supposed to overwrite the field after it is submitted.
From the documentation you will even find a nicer possibility:
Preset on first reply Subject = Re: $Subject
The prevent replies to build a long chain of "Re: Re: Re: ...."
Cheers Andreas |
|
Re: Synchronizing mirror causes corruption of logbook entries with multiple logbooks defined?, posted by Andreas Luedeke on Fri Sep 3 14:43:16 2010
|
| Glenn Horton-Smith wrote: |
|
We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it? [...]
I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized. This suggests it isn't specific to Linux architecture, 64-bit or otherwise.
|
We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.
Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?
Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-) |
|
Re: Synchronizing mirror causes corruption of logbook entries with multiple logbooks defined?, posted by Renee Poutissou on Fri Sep 3 19:04:46 2010
|
| Andreas Luedeke wrote: |
|
| Glenn Horton-Smith wrote: |
|
We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it? [...]
I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized. This suggests it isn't specific to Linux architecture, 64-bit or otherwise.
|
We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.
Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?
Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-)
|
I have been using the mirror mechanism for one year for the online T2K /ND280 (neutrino oscillation experiment at J-PARC, Japan). It has been a savior to allow access to all collaborators to the Elog. The experiment online computers are all behind a double firewall that allow only communication through ssh and http in one direction: from the inside to the outside. The master Elog is located in Canada and accessible remotely to all collaborators. The mirror Elog is located inside the firewall on one of the online machines in Japan and synchronization is setup to run automatically every 5 minutes. There are 10 logbooks defined for each of the sub-detector groups.
At first I encountered a big problem when messages were added on both sides. It turned out that Elog mirroring does not work when the two instances are running on different time zones. After I set the machine in Canada to run on Japan time (JST), no further problems have happened. Postings are routinely entered on either of the Elogs and synchronization works well. This feature is essential to having a workable Elog for the T2K experiment.
I had reported the problem of timezones to Stefan last year. He was going to put it on his wish list.
|
|