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.

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

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

Dear Stefan,

Thank you for your comment. I successfuly compiled the latest elog from source code, and now elogd could work with SSL.

In fact, I reported the case of installation with rpm file. Maybe, the latest elog rpm doesn't support SSL, I guess.
The installtion with rpm file is easier to build the common environment, so I hope the next rpm will support the SSL.

best regards,
Hisataka YOSHIDA

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.

After going through the code of the Python API (https://github.com/paulscherrerinstitute/py_elog/blob/master/elog/logbook.py) I tried the following:
$ python3
>>> from passlib.hash import sha256_crypt
>>> sha256_crypt.hash( 'foobaa', salt='', rounds=5000)[4:]
'waa2sT6eBt.qk0wsucX/nxU5GcqffqlEx6ja5Lg1OR5'
>>> from datetime import datetime
>>> datetime.now().timestamp()
1599039390.964989
$ curl -F cmd=Submit -F exp=labor -F unm=florian -F upwd='waa2sT6eBt.qk0wsucX/nxU5GcqffqlEx6ja5Lg1OR5' -F Encoding=plain -F When=1599039390.964989 -F Author=curl -F Subject="curl test" -F Category=General -F Type=Diary -F Text="foo baa" http://localhost:8080/test/

This worked. It seems to me, that the "-u" option from Curl is not working for elog.

Cheers,
Florian

Hello,

I'm working on new logbook and in one category I'll have many attributes (many more than in attached screenshot).

So here is my question. Is it possible to visually group such attributes with some border, or something like that?

In screenshot you can see what I want to achieve.

Best Regards

Daniel

All,

I would like to know if there is a way in elog to populate a field based on the value of another field. What I want to do is have a field with a few selections (a menu) and another text field that populates based on what I select from the menu.

Is this possible?