Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 732 of 806  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Collapse | Expand  Show only new entries    6445 Entries 
Goto page Previous  1, 2, 3 ... 731, 732, 733 ... 804, 805, 806   Next  
icon5.gif   compiling elog 2.6.1 on solaris platform, posted by Angus Au on Thu Feb 2 03:19:44 2006 
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.
icon1.gif   Problem with auto-increment attribute, posted by Andy on Tue May 24 20:32:08 2005 
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?
icon1.gif   HTTP headers should be parsed case insensitive, posted by André on Mon Jul 22 16:17:55 2024 

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.

    icon2.gif   Re: Invalid Content-Length in header when running behind a load balancer, posted by André on Mon Jul 22 16:30:04 2024 

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

 

 

    icon2.gif   webkit bug, posted by Andrey Pashnin on Mon Jan 2 12:32:13 2023  
FYI

They seem to have accepted the bug report:
https://bugs.webkit.org/show_bug.cgi?id=249923
    icon2.gif   editing on a smartphone, posted by Andrey Pashnin on Wed Jan 4 10:05:38 2023 Screenshot_2023-01-04_at_10.06.02.png 
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! ;)
    icon2.gif   config option?, posted by Andrey Pashnin on Wed Jan 4 11:03:45 2023  
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.
    icon2.gif   wrap "pre" tag in a "div" with fixed width, posted by Andrey Pashnin on Wed Jan 4 11:39:39 2023 (READ)_single_long_line.png(EDIT)_single_long_line.png 
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.
Goto page Previous  1, 2, 3 ... 731, 732, 733 ... 804, 805, 806   Next  
ELOG V3.1.5-3fb85fa6