Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 732 of 806  Not logged in ELOG logo
ID Date Icon Authordown Author Email Category OS ELOG Version Subject
  1644   Thu Feb 2 03:19:44 2006 Question Angus Auangus_au@promina.com.auQuestionOther2.6.1compiling elog 2.6.1 on solaris platform
I came across problem in compiling elog 2.6.1 on solaris platform.

The messages "

# make
gcc -o elog src/elog.c -lutil -lsocket -lnsl
ld: fatal: library -lutil: not found
ld: fatal: File processing errors. No output written to elog
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `elog'

It seems to me that library libutil does not exist on solaris platform.

Is there any fix ? I can compile elog 2.6.0 successfully on solaris.
  1158   Tue May 24 20:32:08 2005 Entry Andynekto@myway.com   Problem with auto-increment attribute
I have a very strange problem with auto-increment attribute. Here is a part of my configuration:

Attributes = Access ID, Harvest Date, Access, Species, PI, Submission date, Stain, Comments
Preset Access ID = MI-05-%03d
Type Harvest date = date
Type Submission date = date

I tried to add new entry, and it's Access ID is MI-05-001. But when I'm adding another entries,
there Access ID is MI-05-006
I found only one mention of using increment in documentation.
What I'm doing wrong?
  69807   Mon Jul 22 16:17:55 2024 Entry Andréandre.althaus@tu-dortmund.deBug reportAll3.1.5HTTP headers should be parsed case insensitive

I'm trying to run elog behind haproxy, but get the error "Invalid Content-Length in header" on posting.

As stated in the manual, haproxy rewrites all headers to lower case.

elogd parses the content-length header case sensitive which is against the HTTP RFC. This might also apply to other headers that get parsed.

For now I'm using the workaround from the manual:

global
  h1-case-adjust content-length Content-Length
  h1-case-adjust content-type Content-Type

backend elog
  option h1-case-adjust-bogus-server
  server elog 127.0.0.1:8080

But as the manual states, this should not be  used as a permanent solution.

  69808   Mon Jul 22 16:30:04 2024 Reply Andréandre.althaus@tu-dortmund.deBug reportLinux3.1.4-3Re: Invalid Content-Length in header when running behind a load balancer

I have the same problem. I found a temporary solution: https://elog.psi.ch/elogs/Forum/69807

Tamas Gal wrote:

I put the ELOG service behind an Apache reverse proxy which is now sitting behind the HAProxy. It works like this, but it's just a workaround. I am pretty sure that ELOG has problems to communicate with HAProxy correctly and it seems that Apache is more forgiving. So that the chain HAProxy -> Apache -> ELOG and vice versa is working.

If anyone manages to figure out what's wrong, I am happy to get rid of the extra reverse proxy layer!

Tamas Gal wrote:

I am still struggling to get ELOG running behind a load balancer and hope to get some advice here. As already reported in https://elog.psi.ch/elogs/Forum/69542 I observed an infinite loop of redirects when prompted to log in and using a non-empty password file. Without a password, the service worked as expected. This was with version 3.1.3.

With the new version 3.1.4-3, I get another error: "Invalid Content-Length in header" when I click on "submit" of a new post. Viewing the logbooks works fine. The instance is currently live and running here: https://elog.test.km3net.de but I might change it anytime due to debugging etc.

This is a kind of difficult thing to debug (I spent the whole day and no progress). The only thing I've found was this post: https://techcommunity.microsoft.com/t5/iis-support-blog/invalid-content-length/ba-p/3038724 where it seems that some responses are not RFC conform and were rejected in the load-balancer.

The load balancer I use is HAProxy, the same as in my old setup where I got the infinite redirects, and I can't find any setting which would work. To my understanding, the most basic setup should work just fine. The SSL termination is on the load-balancer side so ELOG doesn't even have to know anything about it. The configuration is below. I am running a single instance, so there is not even replication with session keep-alive via cookies or anything fancy.

I also want to mention that I am runnin around 30 different services behind the load balancer and none of them are having any issues with the SSL termination or the load-balancing itself, that's why assume that something in ELOG is either non-conform or buggy.

Any thoughts? I'd really like to use the same infrastructure for the ELOG service as for every other service (automatic certificate renewal via letsencrypt, load-balancing, easy movement to other nodes, SSL termination etc.), to minimise the complexity of our Docker Swarm system.

backend be_elog.km3net.de
    mode http
    server-template km3net-elog- 1 km3net-elog_elog:8080 check resolvers docker init-addr libc,none

 

Btw. I am running ELOG with -v but I don't see any error whatsoever in the logs:

km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | GET /demo/ HTTP/1.1
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Received unknown cookie "ios_specific_templates_id"
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Received unknown cookie "rl_anonymous_id"
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Received unknown cookie "rl_group_id"
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Received unknown cookie "rl_group_trait"
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Received unknown cookie "rl_trait"
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Received unknown cookie "rl_user_id"
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Received unknown cookie "logged_out_marketing_header_id"
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Returned 3437 bytes
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | GET / HTTP/1.1
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Returned 120 bytes
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | GET /demo/ HTTP/1.1
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Returned 3518 bytes
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | GET / HTTP/1.1
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Returned 120 bytes
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | GET /demo/ HTTP/1.1
km3net-elog_elog.1.fm8i1eia9l9t@ecap-s021    | Returned 3518 bytes

 

 

  69598   Mon Jan 2 12:32:13 2023 Reply Andrey Pashninkowaraj4stuff@gmail.comInfoAllELOG V3.1.4-493webkit bug
FYI

They seem to have accepted the bug report:
https://bugs.webkit.org/show_bug.cgi?id=249923
  69601   Wed Jan 4 10:05:38 2023 Reply Andrey Pashninkowaraj4stuff@gmail.comBug fixAllELOG V3.1.4-493editing on a smartphone
oh! so, that's the cause of another problem I faced a while ago. 
When people edited an ELOG page on a narrow screen device (a.k.a smartphone) it put the extra CRLF and made the page look like the attachment below 
(it broke the original formatting).

I had to "fix" this by setting the width of the textarea to a huge number... 

However, removing "wrap=hard" solves both these problems! ;)
Attachment 1: Screenshot_2023-01-04_at_10.06.02.png
Screenshot_2023-01-04_at_10.06.02.png
  69604   Wed Jan 4 11:03:45 2023 Reply Andrey Pashninkowaraj4stuff@gmail.comBug fixAllELOG V3.1.4-493config option?
How about adding a config option? 
Ideally, it might be nice to have this option "per record" or "per logbook", but "per instance" should be good enough.
  69605   Wed Jan 4 11:39:39 2023 Reply Andrey Pashninkowaraj4stuff@gmail.comBug fixAllELOG V3.1.4-493wrap "pre" tag in a "div" with fixed width
I'm sorry for being annoying... 
but I have tried to wrap the <pre> tag in a <div> and it seems to do the trick
(the text is a single line with repeating aaa-b-cc sequence)

In the READ mode, the width is limited by the div's width 
(see the first attachment)

In the EDIT mode, the width is only limited by the textarea width
(see the second attachment)

All this is with "wrap=hard" removed. 
Attachment 1: (READ)_single_long_line.png
(READ)_single_long_line.png
Attachment 2: (EDIT)_single_long_line.png
(EDIT)_single_long_line.png
ELOG V3.1.5-3fb85fa6