Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 83 of 806  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Version Subject
  69201   Mon Aug 17 10:34:32 2020 Question Lahreche Abdelmadjidabdelmadjid.lahreche@yahoo.comRequestWindows2006do some changes on .CFG

Hi All,

I would like to have "Permis de verouillage et d'étiquetage 016685-68AF-0031" when I select it.

I don't found where can I make this change

thank you.

 

 

Attachment 1: Elog_1.PNG
Elog_1.PNG
Attachment 2: Elog2.PNG
Elog2.PNG
  69200   Mon Aug 10 09:01:24 2020 Reply Anthonyanthony.weathers@pm.meQuestionLinux3.1.3-1-1Re: Reverse sort by Attribue, but it's only showing the last 6 entries by default.

Thank you, Andreas!  Not sure why I kept overlooking it in the manual.  As for the number of entries when I sort, I'm not sure.  I'll set it up to display a larger number and see what happens.

Andreas Luedeke wrote:

It is described in the manual at https://elog.psi.ch/elog/config.html#general

Entries per page = <number>

Funnily the default is "20". I have no idea why you see 6 entries.

Anthony wrote:

Hi,

I'm trying to use the Sort Attributes option to sort all entries by a user specified date.  The issue I'm running into, is that although I can get it to work, it seems to only display the last 6 entries that I'm sorting by.  If I click "All" to show all the entries, it's sorted perfectly. I'm using:

Sort Attributes = Due Date

Reverse sort = 0

Is there something I'm missing to get this working.  Reading through the manual nothing jumped out at me.

 

 

  69199   Mon Aug 10 08:33:42 2020 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux3.1.4Re: SSL connection drop with large content

Your solution sounds quite good, I will incorporate them in the distribution.

Stefan

HyonSan Seo wrote:

Dear all,

 

I had some difficulty to upload large files (>20MB) with SSL connection. I think it is also related to https://elog.psi.ch/elogs/Forum/68636

During debuging, I found that, when uploading large files, ssl connection is dropped since 'SSL_read' function returns -1.

But it doesn't alway mean broken connection. It may be "SSL_ERROR_WANT_READ".

I changed the "server_loop" function in the source code to "continue" when it is SSL_ERROR_WANT_READ. And it fixed the problem.

Here is my code.


## elogd.c "server_loop" function L30031

                        if (FD_ISSET(_sock, &readfds)) {
#ifdef HAVE_SSL
                          if (_ssl_flag){
                            i = SSL_read(_ssl_con, net_buffer + len, net_buffer_size - len);
                            if(i<=0){
                              int ssl_error=SSL_get_error(_ssl_con,i);    ## check ssl error code
                              if(ssl_error==SSL_ERROR_WANT_READ||ssl_error==SSL_ERROR_WANT_WRITE) continue;    ## if ssl wants more, continue
                            }
                          }
                          else
#endif
                            i = recv(_sock, net_buffer + len, net_buffer_size - len, 0);
 


 

I am ignorant about networking. Some experts on ssl connection would know a better way to deal with this problem.

 

Best,

HyonSan Seo

 

 

  69198   Mon Aug 10 07:56:43 2020 Idea HyonSan Seohyon.san.seo@cern.chBug reportLinux3.1.4SSL connection drop with large content

Dear all,

 

I had some difficulty to upload large files (>20MB) with SSL connection. I think it is also related to https://elog.psi.ch/elogs/Forum/68636

During debuging, I found that, when uploading large files, ssl connection is dropped since 'SSL_read' function returns -1.

But it doesn't alway mean broken connection. It may be "SSL_ERROR_WANT_READ".

I changed the "server_loop" function in the source code to "continue" when it is SSL_ERROR_WANT_READ. And it fixed the problem.

Here is my code.


## elogd.c "server_loop" function L30031

                        if (FD_ISSET(_sock, &readfds)) {
#ifdef HAVE_SSL
                          if (_ssl_flag){
                            i = SSL_read(_ssl_con, net_buffer + len, net_buffer_size - len);
                            if(i<=0){
                              int ssl_error=SSL_get_error(_ssl_con,i);    ## check ssl error code
                              if(ssl_error==SSL_ERROR_WANT_READ||ssl_error==SSL_ERROR_WANT_WRITE) continue;    ## if ssl wants more, continue
                            }
                          }
                          else
#endif
                            i = recv(_sock, net_buffer + len, net_buffer_size - len, 0);
 


 

I am ignorant about networking. Some experts on ssl connection would know a better way to deal with this problem.

 

Best,

HyonSan Seo

 

  69197   Sun Aug 9 20:47:05 2020 Reply Andreas Luedekeandreas.luedeke@psi.chQuestionLinux3.1.3-1-1Re: Reverse sort by Attribue, but it's only showing the last 6 entries by default.

It is described in the manual at https://elog.psi.ch/elog/config.html#general

Entries per page = <number>

Funnily the default is "20". I have no idea why you see 6 entries.

Anthony wrote:

Hi,

I'm trying to use the Sort Attributes option to sort all entries by a user specified date.  The issue I'm running into, is that although I can get it to work, it seems to only display the last 6 entries that I'm sorting by.  If I click "All" to show all the entries, it's sorted perfectly. I'm using:

Sort Attributes = Due Date

Reverse sort = 0

Is there something I'm missing to get this working.  Reading through the manual nothing jumped out at me.

 

  69196   Sun Aug 9 03:41:05 2020 Question Anthonyanthony.weathers@pm.meQuestionLinux3.1.3-1-1Reverse sort by Attribue, but it's only showing the last 6 entries by default.

Hi,

I'm trying to use the Sort Attributes option to sort all entries by a user specified date.  The issue I'm running into, is that although I can get it to work, it seems to only display the last 6 entries that I'm sorting by.  If I click "All" to show all the entries, it's sorted perfectly. I'm using:

Sort Attributes = Due Date

Reverse sort = 0

Is there something I'm missing to get this working.  Reading through the manual nothing jumped out at me.

  69194   Tue Aug 4 13:44:01 2020 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.1.4Re: How to prevent file path leaks on a 404 page

I removed the version info from the 404 error, but you have to recompile elogd from sources. The fix will be included in the next RPM, but that can usually take a few weeks.

Rich Loring wrote:

Hello,

We used the Elog RPM binary installation method to install Elog. Our security scanners are complaining that Elog discloses the version information when you hit a missing page (404 error).  How can I hide this version info? Is there a snippet of code somewhere that I can comment out?

Any help is appreciated.

-Rich

 

  69193   Tue Aug 4 13:38:05 2020 Reply Stefan Rittstefan.ritt@psi.chQuestionWindowsV3.1.4-80633baRe: Record ID corruption

I tried to reproduce the problem with a fresh minimal logbook (the demo one coming from the distribution). Made 60 replies and all went well. So I wonder if it has to do with some special settings in elogd.cfg. Can you reproduce the problem with an empty logbook and an edlog.cfg which contains just the minimal settings?

David Pilgram wrote:

Hi Frank,

Good bit of detective work.  To me it suggests that something as yet undetermined occurs, that, when the 57th reply happens, causes the issue.  If that "something" hasn't happened, all is well.  Apart from Heinz varieties (not true, in fact), 57 isn't an obvious number; nor did it leap out at me at a quick look at the parameters in the coding.  My example of deleting more than 40 entries causing elog to crash was at least consistent, it happened every time.

I'm trying to think what this something might be.  With my (admittedly largeish) database of elog entries, starting elog from a cold start will take minutes of indexing before it will display home page or whatever.   Presumably it must count the number of entries in each thread (as otherwise why always 57?), yet if you stop and restart, it doesn't necessarily need to do the full indexing again - time between restarts I guess, the authors not considering the evil deeds I perform on yymmdda.log entries.

Bare me out on this, I once had software that ran a system, and every Thursday, without fail, it always did a full recalibration on every start up.  Since updates were issued on Fridays, I commented that it was just adding to our pressure, "as if it knew the day of the week"; it really was (and turned out to be) a day-of-the-week bug.  So, I've been right on more than one occasion.  Anything in common with the threads with cross indexing, such as day of the week, day of the month, time, especially if crossing midnight before the 57th reply? 

Another line would be to view the yymmdda.log files while you are making a normal reply.  In my v2.9.2 version, nothing is written until the Submit button is pressed, then either one or two files are modified or one modified and one new one created.  Is that still true with your version?  I ask because clearly one or two entry numbers have somehow already been "reserved" as if opened, but where?  That Autosave =0 looks to be a useful test to do.

Sorry I cannot be more help.  I'm not one of the development team, though I do have experience of (ab)using elog, and I'm a pretty rubbish coder as well.  but I do have some experience in bug finding!

David.

Frank Baptista wrote:

Hi David,

Well, you've made some very interesting observations, and raised some excellent questions.  So, I went back and did some homework, reviewing a number of logbooks to find instances where this strange 'record twist' occurs.  You had asked, "Do you have enough information to decided that this event always happens after x replies?" -- and to my surprise, indeed there was a magic number that I didn't expect to see.  The 57th reply to the original posting was always where the corruption began.  Mind you, we don't always get a corruption on the 57th reply -- most of the time, it works as expected. However, in all the cases where I saw this record twist, it was the 57th reply after the original posting. Go figure.

I also reviewed my elogd.cfg file to see how I handled drafts.  Currently, it does have the flag Save drafts = 0.  What I plan to try next, if only to satisfy my curiosity, is to also add Autosave=0.

I can't thank you enough for your time and feedback...very much appreciated!

Best regards,
Frank

 

David Pilgram wrote:

Hi Frank,

There are two interesting points about the log file. 

1.  Entry 5658 is timestamped later than 5659, but is earlier in the entry list.  It also is "In Reply to" 5659. despite 5659 having not been written (or at least timestamped) at the time that 5658 is.  Might this be a feature of the draft function?  I've not upgraded my elog for a long time now so my version doesn't have the feature - so I cannot test the idea of more than one entry being worked upon at the same time.

2.  Entry 5657 says it is "In Reply to" 5656, but entry 5656 does not reference 5657 in the "Reply to" line, as it should   Again, this might be a feature of the draft function

Could someone be confusing a draft entry with a real one?  Or two attempts to make an entry?

On the idea of large number of entries, elog doesn't handle deleting of a thread of more than 40 replies well - it crashes after deleting the 40th.  This leaves an orphan thread that causes other issues.  Do you have enough information to decided that this event always happens after x replies?

 

Frank Baptista wrote:

Hi David,

Thanks for the quick response!  Well, I'd have to say that the sequence is as tangled as it looks in the logbook -- I've attached a copy of the log file for your reading pleasure. 

This one is definitely a "head-scratcher" for me...it definitely seems like it is more prevalent on log entries with many replies.

Thanks,
Frank

David Pilgram wrote:

Hi,

I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file.  It would be very interesting to see what the 200428a.log file looks li looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch a branch or indeed this same order as the screenshot.  If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second e second entry were created before the "No branches" checking part of the program had been reached.  Not so sure about such an event here unless entry 5658 were already open but not closed?

 

Regards,

David.

Frank Baptista wrote:

Hi all,

I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.

In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber).  We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.

What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 56 5656, 5659, 5657, 5658, 5660, 5661....

Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.

Has anyone else encountered this? 

Thanks,
Frank
 

 

 

 

 

 

 

 

ELOG V3.1.5-3fb85fa6