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

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

Stefan

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, 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
 

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 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 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 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.

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

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?

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

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.

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?

Hi,

Is there a search feature in ELOG.  Basically, we have the topics broken up by categories but within the categories we would like to search by a key word based on the subject to get to a specific topic.

Thanks.
Illam

That question screams: please read the manual! Find command: https://elog.psi.ch/elog/userguide.html#browse

I am moving from a Hyper-V host to a VMware host and created a new elog server. I installed the elog software and did an rsync to get the .cfg file and logbooks to the new server.

rsync -av root@old.elog.server:/usr/local/elog /usr/local/
 

On the new server all of the 2020 entries are missing and there does not appear to be a 2020 logbook on either server but I can still access the 2020 entries on the old server. Where might they be and how do I get them over to the new server.

Old server says version is ELOG V3.1.4-unknown and new server says version is ELOG V3.1.4-966e3dd

Bothe servers a fully updated CentOS 7.

Start your new server interactively with "elogd -v 3" to see all verbose output. You will then see how it indexes all logbooks. If not, you might have a wrong path in elogd.cfg

On the new server in the logbook that should have several 2020 entries it stops on the last entry of 2019.

On the old server after stopping elogd i get:

/usr/sbin/elogd -v 3

Cannot open "elogd.cfg": No such file or directory

Are the files supposed to be in /usr/local/elog or /usr/share/elog? I have both on the old server. I only synced /usr/local/elog to the new server. In any case the Logbook with 2020 entries does not show a 2020 directory.

My backup system also does not show any 2020 logbook directories. It was current up to this week when I started this process.

You can put your files where ever you want, just tell elogd where to find the elogd.cfg file via the "-c" flag. Then tell elogd where to find files in the elogd.cfg file via the "Logbook dir" and "Resource dir" directives.

Stefan

Thank-you. That is good information to have. 

What is the default if you you do not specify anything in elogd.cfg? I assume it is  /usr/local/elog otherwise it would not see the existing logbooks.

With a default Linux RPM install, where else would the logbooks be? Still looking for a 2020 directory on either server.

Bruce

If nothing is specified elogd looks for logbooks in the current directory where it got started under ./logbooks/

No idea what happened to your 2020 logbook.

Hi,

I'm trying to expand the Subject column, when viewing in summary mode, and couldn't find any documentation for it.  Is this possible and if so, how would I do it.

Thanks in advance for your help.

Illam

You can't directly change individual columns, but you can reduce the "Text" column. This is done in themes/default/elog.css. Search for "listtitle2" and change or remove the line "width:100%". This makes the text column narrower, leaving more space for the subject column.

Hi Stefan,

Thanks for your prompt follow up.  I did try commenting of the width statement for listtitle2 and also reducing it to 40% but it did not work.  I restarted elogd daemon and I don't see the columns changing.  I also tried putting a percentage number (40%) for listtitle1 just to try and no change either.  Appreciate your help.

Thanks.

Illam

Anyone who knows me knows I (ab)use elog a lot.   And this one is another of a long list of cheats and work arounds rather than modifying the code properly.

In summary mode, the top row are titles, and if they are long, they will dominate the width of that column.  Similarly if they are short, if entries under that title are either non-existant or even shorter.  Sometimes entries below the title will dominate, e.g. entries under "Date" title.

I assume your entries under the title in question are things like more than one word, such that they get split into two rows within that cell.  Sometimes that can look very untidy.  However, if you want the column wider than the title is given, you can pad out the title with "&nbsp;" (without the "").  Either on both sides for a centred title, or on the right for left justified.  Or between words if the title has more than one.  (Sorry for this edit, I hit submit button rather than preview).

I can think of two reasons why you don't see a change:

1) You modified the wrong file. The elog.css file is under elog/themes/default/elog.css. If you "install" elog, it might go into your installation directory. So check if you have more than one file with this name.

2) After the change, you did not reload the page in your browser.

Try to request the file directly in your browser with <url to elog>/logbook/elog.css then you will see the actual file your browser is using. Make sure your modification is present there.

Stefan

Hi Stefan,

I have only one elog.css file in the default directory and the installation path is the same one that I'm using. Basically, I'm using off of the installed path.  I also tried, modifying the file and calling it elog_mod.css and then specified CSS=<path>/elog_mod.css and started the server again.  I did not see any changes.  Is there something else I'm missing here.

Thanks.
Illam

Hi Everyone,

I tried using this $@MID@$ in JS as a variable and cannot doit. I researched a little and found no answer on special character usage. If anyone knows, please lemme know. I also tried breifly in Elogd to change it to something like just MID, but need a better editor as  (Kate) is not saving the program back in correct iso (character) format. So I thought I'd pose the question in the meanwhile.

Thanks, John

No idea what you are talking about. $@MID@$ is used in the database files to indicate the start of a new message. It is not used on any elog web page. If you want to put the message ID on your web page, you should use the variable "$message id" as written in the documentation. You say JS, where is your JS running? You wrote a JS program to work on the raw elog database files? Or you wrote an extension to run in your browse? You have to be a bit clearer.

Stefan

Hi,

I'm trying to expand the Subject column, when viewing in summary mode, and couldn't find any documentation for it.  Is this possible and if so, how would I do it.

Thanks in advance for your help.

Illam

Hi, 

in commit 1812e7c, specifying CFLAGS to make command in elog.spec, renders all other settings in Makefile void. That is, if I want to include any of KRB5, LDAP, PAM support, and change makefile accordingly, then when producing rpm they are not taken into account. Anyway, CFLAGS in Makefile are already set to the same defaults, so why it is redefined in spec file?

best

Janusz

Hi,

You rights, CFLAGS should not be in specfile to take care of distrib env.

Btw, I sent in the past an update for build process of Stefan delivery to generate src.rpm file copatible to tarball version. I think Stefan did not have time yet to test and to check.

With the enclosed SPEC file, you can build ELOG with options at rpmbulld command w/o modifying sources. For exemple,

rpm -i elog-.....src.rpm

rpmbuild -bb --with ssl --with pam --with ldap --with krb5 ~/rpmbuild/SPECS/elog.spec

I enclosed also the SRPMS i used for my projects. Be careful, It's maybe not uptodate of last GIT version or PSI releases... but you can test it on your RPM distrib. It should be nice to hare your feedback.

Bye,

Laurent

Thanks for the answer, I will try with your specfile

best

Janusz