Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 563 of 808  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Hide attachments  Show only new entries    6457 Entries 
Goto page Previous  1, 2, 3 ... 562, 563, 564 ... 806, 807, 808   Next  
ID Date Icon Author Author Email Category OS ELOG Versiondown Subject
  66758   Sat Mar 13 09:40:37 2010 Reply Mirza Ehsanmirza@cpjeddah.comBug reportWindows2.6.1-1681Re: eLog crash

Stefan Ritt wrote:

Mirza Ehsan wrote:

I am using eLog ELOG V2.6.1-1681 which has 7 log books under 8 categories. Out of 7 log books, 2 are daily used. It happened that two weeks back. I modified information on two log books which were not used for quite longtime. Hence using CONFIG, I updated these log books, changing text etc. After that eLog in general started giving error. Any time when we click SUBMIT button in any log book, eLog shows page not found. That submit crashes eLog and as a result elogd service stops. Restarting elogd service, eLog operation comes back and the log which I submitted was actualy saved. Difficulty is that this problem is happening with every single submit action. 

I searched forum and learnt that upgrading eLog to newest version 2.7.8 will solve this problem. Upgrade created more problems, I was not able to open any log, authentication was not accepted. I restored that backup and went back to previous version. eLog started working but with submit error.

If any one can help me in fixing this problem

I propose that you get 2.7.8 working. If the authentication fails, try do do password recovery, or recreated the accounts. 

 Thanks for the reply. I found problem with existing version. I opened log book group  without  opening log book details in configuration, that is why at submitting or opening elog was not able to find log book for that group and was getting lost.

Regarding moving to 2.7.8, I want to know that in this new version file location for pwd and log books will remain same or are changed. If changed then I have to change location manually. Also how I can perform password recovery.

  1764   Wed Mar 8 22:33:56 2006 Warning Steve Jonessteve.jones@freescale.comBug reportAll2.6.1-1671OPTION <attribute> not working right in [ global <name>] Top Group
I've verified that when the following is part of the definition of a [logbook] OR is part of a regular [global] config:
Options Completed = Open{a}, Closed{b}
{a} Preset CompletedDate = 
{b} Preset CompletedDate = $date

. . . the intended function (when option "Open" is selected the attribute "CompletedDate" is cleared; when the option "Closed" is selected the attribute "CompletedDate" is filled with the current date)

When this same code is moved to a [global <name>] config the function no longer works (the attribute "CompletedDate" is not set).

This for me is a show stopper as using Top Group has allowed me to create and use logbooks in a way that I could not under the old way (single [global]. I have verified that the same thing happens under 2.5.9.
  1765   Thu Mar 9 04:46:42 2006 Warning Steve Jonessteve.jones@freescale.comBug reportAll2.6.1-1671Removing 'New' from "List Menu commands" prevents saving elogd.cfg
Strange as it mmay seem, when I attempt to remove the "New" menu item from "List Menu commands" in a logbook section, I am no longer able to Save the config file -- I am presented with a message saying "Error: Command "Save" not allowed". I have to manually edit the file, add that menu item back in, and then all is ok. This is on the system where I am using 'Top Groups', so the logbook is a part of one of the top groups.
  1766   Thu Mar 9 06:04:46 2006 Question Steve Jonessteve.jones@freescale.comBug reportAll2.6.1-1671Strange "bug?" report - disappearing data when attribute is "Locked"

Steve Jones wrote:
I have come across an issue where an attribute value is "blanked" upon either editing or replying. The interesting thing is this is a logbook entry that was "Moved" from one logbook to another, all under the same Top Group. All configs are done under the [global <topgroup>] so the attribute is not being reset on purpose. Most interesting of all is this only happens:

  • if the attribute is "locked" (the logbook being moved "To" locks most attributes)
  • if the attribute is of type "date"
  • if the logbook entry had been "moved" from another logbook


If the logbook entry is subsequently moved back, all works as it should - even the locked date attributes.
temporary workaround is to "unlock" the date attributes - which really messes with things if people decide to change the dates.
  1769   Mon Mar 13 12:51:36 2006 Question Yoshio ImaiBug reportLinux2.6.1-1671Broken thread structure in Forum?
Hi!

I noticed that this thread seems to be broken in the Forum. When I view the thread start in single view (http://midas.psi.ch/elogs/Forum/1739), I have access to all subsequent posts, but the first reply seems to be interpreted like a new thread, i.e. when clicking onto it (http://midas.psi.ch/elogs/Forum/1741), the thread start is no longer displayed and accessible in the list of posts. Is this intentional, or is it a bug?

Yoshio
  1770   Mon Mar 13 12:57:33 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux2.6.1-1671Broken thread structure in Forum?

Yoshio Imai wrote:
I noticed that this thread seems to be broken in the Forum. When I view the thread start in single view (http://midas.psi.ch/elogs/Forum/1739), I have access to all subsequent posts, but the first reply seems to be interpreted like a new thread, i.e. when clicking onto it (http://midas.psi.ch/elogs/Forum/1741), the thread start is no longer displayed and accessible in the list of posts. Is this intentional, or is it a bug?


Some how it got screwed up, such that ID 1741 did not have a back-link to 1739. I have no clue how this could have happened, but I fixed it by manually editing the log file.
  1771   Mon Mar 13 13:19:09 2006 Reply Yoshio ImaiBug reportLinux2.6.1-1671Broken thread structure in Forum?

Stefan Ritt wrote:
I have no clue how this could have happened, but I fixed it by manually editing the log file.


I also have never come across anything like this in our logbooks (approx. 10000 entries), so it doesn't look like a bug.
  1799   Thu Apr 6 20:24:06 2006 Question Yoshio ImaiQuestionLinux2.6.1-1671elog client authentication and attachment comment
Hi again!

I have two questions, one concerning authentication methods for the elog client. Until revision 1642, it was possible to submit entries to a password-protected logbook using the elog client without supplying authentication information. With revision 1671 this is no longer possible. In principle this is good. However, many of our run control programs use the elog client (via rsh to the elog server computer) to submit automatic entries, which fails now. In order for this mechanism to work again, we would have to change the command-line call in the sources, including now the password in clear text. Since this can be considered a security issue, we would like to avoid it if at all possible. I guess my request would go in the direction of PAM support, but would it be possible to revert to the old behaviour as an option? (If you tell me where in the code to look, we could probably also comment out the respective lines ourselves so that you don't have extra work...)

The second remark is about attachment comments. When editing a logbook entry, the attachment upload buttons appear again, but without the comment. Shouldn't it be there, too?

Thanks,

Yoshio
Goto page Previous  1, 2, 3 ... 562, 563, 564 ... 806, 807, 808   Next  
ELOG V3.1.5-3fb85fa6