Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 185 of 806  Not logged in ELOG logo
ID Date Icondown Author Author Email Category OS ELOG Version Subject
  2049   Wed Nov 8 07:59:01 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportWindowsV2.6.2-172Re: checkbox

deletoille wrote:
I found a small Bug when I create an entry. I activate a checkbox (attachement1) but when I upload a file, the activation disappears (attachement 2). I have to activate again the checkbox.
Is it something I can do?


I tried with V2.6.2-1741 and the problem was not there. It was fixed some time ago, so it should have worked in 1723 as well. Can you try the minimal example coming with the distribution, just by adding one MOptions attribute, like:
[global]
port = 8080

[demo]
Attributes = Author, Type
MOptions Type = Routine, Software Installation, Problem Fixed, Configuration, Other

and see if it work there? If it works correctly there but not with your config file, please send me your config file and I will try to reproduce the problem.
  2050   Wed Nov 8 08:20:34 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.2-1714SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8)

Steve Jones wrote:
BUG: In the initial comment section of elogd_fancy.cfg the line
# This [global] section contains settings common to all logbooks
is not parsed correctly as a comment and the embedded [global] is picked up and confuses elogd, eg., elogd will not pickup the port=8080 option. Taking "[global]" out of the comment restores fucntionality. I recommend checking to make sure that the config file checking routine ignores *entire* lines starting with a comment char;


Acknowledged. The problem was that the section between the line
# This [global] section contains settings common to all logbooks
and the real
 [global] 
section was interpreted as the global section, and thus the "real" one was omitted. I changed the code now such that all lines starting with a '#' or ';' are completely skipped, that fixes the problem. The fix is contained in revision 1745.


Steve Jones wrote:
ISSUE: The option
Logbook dir = 
causes an enormous amount of problems, and this may be limited to elog installs that exist in NFS space (as opposed to local disk). If the default is left alone elogd appears to work fine; Try and override and the fun begins. The previous attached traces show that once going into daemon mode none of the logbook dirs can be found nor indexed. The workaround is to use the default "logbooks" dir. Perhaps the routine that creates the default (if not found) should be the same as the one that creates the override (?).


That's weird. Have you tried to specify a full path for the logbook, like /nfs/some/directory ? The only difference of the daemon mode compared to the normal mode is that elogd does a cd to the root ('/'). If you specify logbook dir relative to the starting directory, like 'some/subdir', elogd will the try to access it under '/some/subdir', where it might not have read/write privileges.
  2051   Wed Nov 8 12:55:58 2006 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8)

Stefan Ritt wrote:

Steve Jones wrote:
BUG: In the initial comment section of elogd_fancy.cfg the line
# This [global] section contains settings common to all logbooks
is not parsed correctly as a comment and the embedded [global] is picked up and confuses elogd, eg., elogd will not pickup the port=8080 option. Taking "[global]" out of the comment restores fucntionality. I recommend checking to make sure that the config file checking routine ignores *entire* lines starting with a comment char;


Acknowledged. The problem was that the section between the line
# This [global] section contains settings common to all logbooks
and the real
 [global] 
section was interpreted as the global section, and thus the "real" one was omitted. I changed the code now such that all lines starting with a '#' or ';' are completely skipped, that fixes the problem. The fix is contained in revision 1745.


Steve Jones wrote:
ISSUE: The option
Logbook dir = 
causes an enormous amount of problems, and this may be limited to elog installs that exist in NFS space (as opposed to local disk). If the default is left alone elogd appears to work fine; Try and override and the fun begins. The previous attached traces show that once going into daemon mode none of the logbook dirs can be found nor indexed. The workaround is to use the default "logbooks" dir. Perhaps the routine that creates the default (if not found) should be the same as the one that creates the override (?).


That's weird. Have you tried to specify a full path for the logbook, like /nfs/some/directory ? The only difference of the daemon mode compared to the normal mode is that elogd does a cd to the root ('/'). If you specify logbook dir relative to the starting directory, like 'some/subdir', elogd will the try to access it under '/some/subdir', where it might not have read/write privileges.



Quote:
Very weird. No, I did not try an absolute path - but I did notice the attempt to "cd /" in the truss output. In fact, it was immediately after that "cd /" test that things appeared to start not working - basically, elogd could not find anything.

I'm putting this on hold for the time being as I now have test systems going into production. I'll be able to test next week.

  2052   Wed Nov 8 13:07:31 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.2-1714SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode

Steve Jones wrote:
Very weird. No, I did not try an absolute path - but I did notice the attempt to "cd /" in the truss output. In fact, it was immediately after that "cd /" test that things appeared to start not working - basically, elogd could not find anything.


The "cd /" is mandatory for daemons according to Unix standards. If a daemon gets started on an NFS subtree, that subtree cannot be unmounted anymore. Therefor it's required that all daemons cd to root, such that the NFS subtree can freely be mounted and unmounted. I therefore use absolute paths in all my statements of elogd.cfg.
  2054   Wed Nov 8 15:39:42 2006 Reply deletoillexavier.deletoille@synchrotron-soleil.frBug reportWindows2.6.2-1746Re: checkbox

Stefan Ritt wrote:

deletoille wrote:
I found a small Bug when I create an entry. I activate a checkbox (attachement1) but when I upload a file, the activation disappears (attachement 2). I have to activate again the checkbox.
Is it something I can do?


I tried with V2.6.2-1741 and the problem was not there. It was fixed some time ago, so it should have worked in 1723 as well. Can you try the minimal example coming with the distribution, just by adding one MOptions attribute, like:
[global]
port = 8080

[demo]
Attributes = Author, Type
MOptions Type = Routine, Software Installation, Problem Fixed, Configuration, Other

and see if it work there? If it works correctly there but not with your config file, please send me your config file and I will try to reproduce the problem.



You're right it works
It must be in my programming method
I share you my config file.
Thanks for your help
Attachment 1: Elog_08_11_06.doc
  2055   Thu Nov 9 20:45:32 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionWindows2.6.2.1723Re: Conditional Email Notification by a text file

Steve Jones wrote:

An Thai wrote:

Steve Jones wrote:

An Thai wrote:
Hello,

I try to email by using a email text file to reduce the admin work.
  • MOptions Team = EUROPE, ASIA, AFRICA, AMERICA
  • Email Team EUROPE = $shell(type C:\EuropeEmailList.txt)

but i get always Email sent to Shell execution not enabled via -x flag

Is this feature not supported by ELOG or did i use the wrong syntax?

Thank you in advance.




Quote:
You need to start elogd with the "-x" flag


Yes, i did it. But the problem is still there.
I exactly tried 50 times by submit a new entry and got only 3 times passed. 47 another cases i got:
"Error sending Email via "192.168.2.20": 5.5.2 Need Rcpt command".
I run elogd -v and see:
"Email Team EUROPE to Shell execution not enable via -x flag"



Steve Jones wrote:

Well, it looks like you are getting the text "Shell execution not enable via -x flag" put into the EUROPE attribute then the email server is attempting to send email to the email address "Shell execution not enable via -x flag", which is clearly not a valid address thus the "Error sending Email via "192.168.2.20": 5.5.2 Need Rcpt command".

You need to run run "elogd -v -x" then look for the errors. You also might try a more simpler test like "Preset Team EUROPE = = $shell(type C:\EuropeEmailList.txt)" and then see what is returned. It makes it simpler and removes the email error from the equation.


That's a very interesting idea of setting up mailing lists I never thought about. I tried myself and it works fine. Just as Steve says run "elogd -v -x" to see what happens. Also make sure that EuropeEmailList.txt contains only a single line with comma-separated email addresses, just as you would enter them in the config file.
  2056   Thu Nov 9 20:59:01 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.6.2-1739Re: calling a shell in the Options tag

Alexandre Lindote wrote:
Hi,

is it possible to run a shell script in an "Options" tag, as it is with the "Preset", "Subst", and so on?
I need to have something like this:

Options Update of = $shell(/home/alex/zeplin3/elog/z3elog-mirror/documents/ext_docs.sh MinGen)

the script returns a line with comma separated values...

Thanks

Alex


Interesting idea, but substitutions only work for config setting where the documentation explicitly states so. The complete list comes here:

  • Preset <attibute>
  • Preset on reply <attribute>
  • Preset on duplicate <attribute>
  • Subst <attribute>
  • Subst on reply <attribute>
  • Subst on edit <attribute>
  • Change <attribute>
  • Email <attribute> <value>
  • Use email from
  • Use Email heading
  • Use Email subject
  • Bottom text
  • Top text
  • Edit page title
  • Prepend on edit
  • Append on edit
  • Append on reply
  • Quote on reply
  • Preset text
  • Page title
  • RSS title
  • List page title

Doing shell execution for all configuration settings would slow down the server too much.
  2057   Thu Nov 9 21:03:03 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.6.2-1699Re: ELCode

Alexandre Lindote wrote:

Alexandre Lindote wrote:
Hi,

can you think of any obvious reason why the ELCode would not work in the logbooks I set up?


Ok, I think I found the problem... For some reason the elcode.js file was only in /usr/local/elog/scripts, but it was supposed to be in
/usr/local/elog/themes/default/ as well.
Creating a symlink between the two solved that problem. I can now do most things with the ELCode, but inserting images is still failing. I get this message from the firefox javascript console:

text.value has no properties (line 32 of elcode.js)

Any thoughts?

Alex


That's really strange. In the forum (http://midas.psi.ch/elogs/Forum), I have the elcode.js only in /usr/local/elog/scripts, and it works as you can try out yourself. Getting your javascript error might indicate that you have an old version of elcode.js combined with a newer executable of elogd. Try to update it.
ELOG V3.1.5-3fb85fa6