We were running ELOG for many many years in our experiments and the instance was operated on a Debian XEN server as a container. I am now trying to migrate it into our Docker Swarm cluster and I am using the https://hub.docker.com/r/de1lz/elog-docker Docker image, which works very well with our logbooks when I run it as a single container. However, when I put the container behind my load balancer (HAProxy) using the simple HTTP mode (which works very well for all the other HTTP-based services) with this simple configuration:

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

I get a "too many redirects" error when I try to access one of the logbooks. The starting page works fine, but every other link leads to a pile-up of redirects.

Here is the current instance running, where you can see the behaviour: https://elog.test.km3net.de (all log entries deleted and only two logbooks activated)

My question is: what kind of redirect could go wrong here? I don't know how the internal HTTP server of ELOG works, but maybe someone faced similar issues.

My ELOG configuration is also pretty basic, and as I wrote above, everything works when I run it without the load balancer (single instance at the moment). Here is the top part of the configuration, it contains a few dozens of logbooks but they are configured the very same way. 

;User Settings
;=============
Password file = login.xml
Admin user = km3net_admin
Self register = 0
Allow password change = 0
Allow config = km3net_admin

;Group Settings:
;====
Group ELOGKM3NET = Operations IT, Operations FR

[Operations IT]
Subdir = Operations_IT
Theme = default
Default encoding = 0
Comment = KM3NeT IT Detector Operations
Attributes = Author, Type, Subject
Options Author = A, B, C
Options Type = PPM-DOM, PPM-DU, Comment, Power cut, New run
Extendable Options = Type
Required Attributes = Author, Type, Subject
Page Title = ELOG - $subject
;Sort Attributes = Author, Type
Quick filter = Date, Type, Author
Resubmit default = 2
Reverse sort = 1
Menu commands = List, New, Edit, Reply, Duplicate, Find, Config, Help, Logout
Preset on first reply Subject = Re: $Subject
Preset on reply author =

Probably you need a setting

URL = https://elog.test.km3net.de

or so in your elogd.cfg file.

Stefan

Thanks for the quick reply! Sorry, I forgot to paste the "global" part of the config, I have that URL already set:

[global]
;Main Settings
;=============
Usr = elog
Grp = elog
port = 8080
SSL = 0
URL = https://elog.test.km3net.de
Title image = <img border=0 src="KM3NeT_logo.png" alt="KM3NeT logo" height="35px">
;SMTP host = smtp.fau.de
Display mode = summary
Thumbnail size = 500>
List Menu text = clock.html
Menu text = clock.html

I also tried the default configuration (example config) and it that works behind the load balancer. So I guess it's related to the password-page, which causes this redirect loop? Our logbooks are all password protected, so when a logbook URL is clicked, it should first present the login-form, and that's where it chokes.

Yeah, after you enter a password, elog redirects to what it finds in "URL". You can trace that by opening "development tools" in Google Chrome, go to "network" and watch packets going back and forth. I never worked with the load balancer, but maybe you need a different "URL" containing a '/' at the end?

My problem is that I don't even reach the page where I can enter a password. If you go to https://elog.test.km3net.de and click on a logbook, you'll see that it immediately goes into a redirect loop. I already logged the routing but there is nothing else...

Attached is the log, where you can see that `Operations+IT` redirects to `Operations+IT/` and that redirects to `Operations+IT` again, which then goes to `elog.test.km3net.de` and `Operations+IT` again etc. etc.

EDIT: I  use the very same load balancer confugration for dozens of other services incl. Apache, Nginx, GitLab, Mattermost, RocketChat etc. and all work fine. As written before, also the "example" logbook works (without password protection).

I also tried `/` at the end of the URL but it has no effect.

I am pretty clueless currently...

Yes I see the redirects. You say with the example logbook it works, right? Is it the password protection which triggers the problem or anything else? Does it work if you take out the password protection? The key is to identify which setting in your config file triggers the problem, so you can bracket the problem down between the example logbook and your logbook definition.

Yes, I used the empty `passwd` file from example. When I then click on one of the logbooks, I get to the page where I can register a user (see attached screenshot). After clickin on "Save" for the user registration, I again get the redirect error. Once there is a registered user (i.e. a non-empty password file) the redirect issue is persistent. Any idea where the problem might be? I just emptied the password file again, so you can have a one-shot, if you like.

Btw. I have SSL termination in the load balancer, so ELOG does not need to do any SSL related things (the swarm is in a locally isolated network, so all internal communication between the load balancer and the swarm machines are safe). Maybe that's the issue? On the other hand, the main page loads fine and uses SSL termination too, so I don't know, maybe there is logic behind the authentication which collides with the SSL termination.

The issue is still present and now it's quite urgent to move this last service into the Swarm. Does anyone maybe have an idea what's wrong? To sum up: if there is a non-empty password file, the login page chokes in an infinite loop of redirects. I am using the same HAProxy load balancer configuration as for all the other services (running Apache, NGINX, GitLab, XWiki, etc.):

backend be_elog.km3net.de
    mode http

    option forwardfor except 127.0.0.1
    http-request add-header X-Forwarded-Proto https if { ssl_fc }

    server-template km3net-elog- 1 km3net-elog_elog:8080 check resolvers docker init-addr libc,none

Dear Stefan, 

There is a problem with editing an Elog page in "plain" format with the following "User Agent" :

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15"

It duplicates the newline symbols such that "1<CRLF>2" becomes "1<CRLF><CRLF>2". If edited again - "1<CRLF><CRLF><CRLF><CRLF>2".

I blame the new version of the Apple WebKit. 

It works fine with Chrome (user agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"). But fails with Safari. 
 

Could you please have a look? 

Thank you in advance, 

Andrey Pashnin

AMS collaboration

It shound't be a "bug report", sorry. I have changed the category to "Info".

It seems to be really a bug in the WebKit core. I have created a bug report there. For reference: https://bugs.webkit.org/show_bug.cgi?id=249923

I am going to try to patch the ELOG code to handle the content of the textarea in the "plain" format.... it doesn't seem possible though. 

FYI.

Removing "wrap=hard" on the line #11461 in the elogd.cxx file resolves my problem.

- rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);*/
+ rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);

- rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);
+ rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);

my vote is to remove "wrap=hard":

1) I try to read the specs and my head explodes: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
2) textarea should just accept input typed by user, should not try to "neatify" it. if user wants long lines, we should let them.
3) this bug (introduced in recent safari, the best I can tell)

K.O.

FYI

They seem to have accepted the bug report:
https://bugs.webkit.org/show_bug.cgi?id=249923

> - rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);
> + rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
> 
> my vote is to remove "wrap=hard":
> 
> 1) I try to read the specs and my head explodes: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
> 2) textarea should just accept input typed by user, should not try to "neatify" it. if user wants long lines, we should let them.
> 3) this bug (introduced in recent safari, the best I can tell)
> 
> K.O.

I agree with K.O. Does anybody see a problem in removing "wrap=hard"? 

It was there more for historical reasons. In the old days screens were not so wide and wrapping was more of an issue.
People tended to write longer lines and complained that the long lines got reformatted differently for different screen
sizes. So by adding hard CRLF the formatting looked the same on different screens. These days this is not such an issue
any more and I agree with 2) above. If the user wants a long line, the user should get it.

Stefan

Ahh, now I remember. Well, the I put that in like 25 years ago ;-)

Let's assume the user write a very long line and relies on the wrapping of the text box. So the input might look like the 
first attachment. Then the user hits submit and gets just one long line (second attachment) and has to scroll one kilometre
to the right to see the full line. So there is an inconsistency between the entry form and what the user sees after the
submission. Having "wrap=hard" tells the browser to put CRLF where the wrapping in the textarea happens, so the text looks
the same during entry and after submission. If we remove the "wrap=hard", we would be back to the situation below in the two
attachments.

Opinions?

Stefan

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! ;)

Yepp, that's right. But without the "wrap=hard", you could get one single long line which is almost impossible to read. So there is no perfect solution for all cases. I see three options

1) Remove "wrap=hard" and let the user do as the user wants. This can lead to very long lines almost impossible to read.
2) Keep "wrap=hard" and rely on the browser to put in CRLF between lines according to the textarea box during input. The result will then be the same as during editing. Of course this might 
require to make the textarea width wide enough on small screens not to get too many CRLFs. The default "Message width" is 78 chars, but on modern browsers some JavaScript code automatically sets 
the width to equal the screen width which normally is wider.
3) Add artificial CRCL like every 40 or 80 chars. This is the "beautifying" K.O. mentioned and will never be perfect. Not sure if elog should touch the text the user enters.

Looking at the three options, I kind of conclude that 2) would still be the best.

Stefan

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.

Ok, I added an option

Hard wrap = 0 | 1

with the default being "1", so same behaviour as before. If you set this now to zero, you turn it off.

Now waiting for the first people complaining about the very long lines not being readable...

Best,
Stefan

That's great! Thank you very much. 

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. 

Didn't work for me. The text is just truncated after the width and no extra lines are added.

Sorry, I forgot to mention that I also added some styles to the <pre> tag:
style="white-space: normal"
(see the screenshot on my previous post)

> Sorry, I forgot to mention that I also added some styles to the <pre> tag:
> style="white-space: normal"
> (see the screenshot on my previous post)

Actually the

style="white-space: normal"

makes the difference, the <div> is not necessary at all!

But I'm not sure that "white-space: normal" is what we want. All manual line breaks in an entry are collapsed and you get just one text block without any new line. See here

https://developer.mozilla.org/en-US/docs/Web/CSS/white-space

I guess we want "white-space: pre-wrap" which keeps the old line breaks.

You can try that out by changing elog.css:

--- a/themes/default/elog.css
+++ b/themes/default/elog.css
@@ -475,6 +475,7 @@ td {

 .messagepre {
   font-family:'lucida console',courier,monospace;
+  white-space:pre-wrap;
 }

and see the effect. If you like it, just keep it. No need to recompile elogd.cxx.

Stefan

> I guess we want "white-space: pre-wrap" which keeps the old line breaks.

Yep. You're right. Thanks!

Hello, the following URL

https://foo.bar/elog/Shift+Reports/?new_user_name=a2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.com&new_full_name=a2seferewd%40fanneat.com&new_user_email=a2seferewd%40fanneat.com&newpwd=asdf&newpwd2=asdf&cmd=Save

causes elog 3.1.4 to crash. I attach full GDB trace

(gdb) set height 0
(gdb) set print elements 0
(gdb) set print frame-arguments all
(gdb) thread apply all backtrace

Thread 1 (Thread 0x7fc6d1624840 (LWP 1126)):
#0  0x00007fc6d06c6387 in raise () from /lib64/libc.so.6
#1  0x00007fc6d06c7a78 in abort () from /lib64/libc.so.6
#2  0x00007fc6d0708f67 in __libc_message () from /lib64/libc.so.6
#3  0x00007fc6d07a87a7 in __fortify_fail () from /lib64/libc.so.6
#4  0x00007fc6d07a6922 in __chk_fail () from /lib64/libc.so.6
#5  0x00007fc6d07a5e2b in _IO_str_chk_overflow () from /lib64/libc.so.6
#6  0x00007fc6d070d031 in __GI__IO_default_xsputn () from /lib64/libc.so.6
#7  0x00007fc6d06dd033 in vfprintf () from /lib64/libc.so.6
#8  0x00007fc6d07a5eb8 in __vsprintf_chk () from /lib64/libc.so.6
#9  0x00007fc6d07a5e0d in __sprintf_chk () from /lib64/libc.so.6
#10 0x0000000000423b5b in sprintf (__fmt=<optimized out>, __s=<optimized out>) at /usr/include/bits/stdio2.h:33
#11 get_user_line (lbs=<optimized out>, lbs@entry=0x2833748, 
    user=user@entry=0x7fffc84d0780 "a2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.combasar", password=password@entry=0x0, full_name=full_name@entry=0x0, email=email@entry=0x0, email_notify=email_notify@entry=0x0, 
    last_logout=last_logout@entry=0x0, inactive=inactive@entry=0x0) at src/elogd.c:25739
#12 0x0000000000433d0a in save_user_config (lbs=lbs@entry=0x2833748, 
    user=0x7704fc <_value+1500> "a2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.com", new_user=new_user@entry=1) at src/elogd.c:13343
#13 0x0000000000456068 in do_self_register (lbs=0x2833748, command=0x7fffc84d2650 "Save") at src/elogd.c:26768
#14 0x000000000045c1f7 in interprete (lbook=lbook@entry=0x7fffc84f92f0 "Shift Reports", path=path@entry=0x7fffc84d4430 "") at src/elogd.c:27594
#15 0x000000000045ecc6 in decode_get (logbook=logbook@entry=0x7fffc84f92f0 "Shift Reports", string=<optimized out>) at src/elogd.c:28393
#16 0x0000000000460970 in process_http_request (request=<optimized out>, 
    request@entry=0x284bee8 "GET /Shift+Reports/?new_user_name=a2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.coma2seferewd%402sefddsfgfd.com&new_full_name=a2seferewd%40fanneat.com&new_user_email=a2seferewd%40fanneat.com&newpwd=asdf&newpwd2=asdf&cmd=Save", i_conn=i_conn@entry=1) at src/elogd.c:29201
#17 0x00000000004623d2 in server_loop () at src/elogd.c:30212
#18 0x0000000000404209 in main (argc=8, argv=0x7fffc84fb6c8) at src/elogd.c:3123

I added a user name validation in the current version.

Stefan

Dear All,

Just want to come back to this issue I faced.

In the config file, I call an html form to format input. The way I call the html file inside my config file is described below.

My point is, even if I am already logged in, each time I try to submit an html form, it sais I am not logged in ...

please refer to the corresponding form to see the screenshots.

Many thanks

Hayg

------->

that is strange since I logged in ... 

It seems like when I go in the shift check topic in the elog, it does not get my login id ... is there something coming from the HTML file that should be set in order to get the login from elog ?

see in the attached image : I am logged in but I still need to feed the Author item. And even If I fill it, 

And then if I Click on new to write a new filling form, author is not filled as you could see on the second image "Author ?"  ...

so I don' see from where appears the problem

When you log in manually to a logbook, a session ID is created and stored in a cookie "sid". On your shift check list you need some code to copy this session ID into your current form. In the code form 2010, I used "unm" and "upwd", but this was removed since it's not safe. So now you need somethign like:

<input type="hidden" name="sid" id="sid">

and

document.getElementById('sid').value = get_cookie('sid');

in your init code.

I haven't tried that in the past 12 years so no guarantee that it should work.

Stefan

I think this is a bug report. 
However, I am not sure whether the problem is in the new version of Apple's WebKit (15.4) or in the ELOG itself.

When we edit an ELOG record with Safari (as of version 15.4, new WebKit features added) the number of "newline" symbols (actually LF, 0xA) are doubled.

So, for instance, if I edit the following page (1 LF symbol between "aaa" and "bbb"):
```
aaa
bbb
```

then after a "Submit" (without actually any changes) the record becomes (2 LF symbols):

```
aaa

bbb
```

then after a "Submit" (without actually any changes) the record becomes (4 LF symbols in between):
```
aaa



bbb
```

NOTE: The LF symbol at the end (after the "bbb" line) does NOT get duplicated (it gets truncated, I believe).


Our current ELOG version is "ELOG V3.1.4-4936b76".
Could you please have a look? 

I have just setup a new ELOG server on another machine. I took the latest source code from here: http://elog.psi.ch/elog/download/tar/elog-latest.tar.gz. Compiled it and ran. 
Still the same problem with Safari.

see https://elog.psi.ch/elogs/Forum/69594

I added a reply to my previous post about this issue (a few months ago) to point to the solution, but ELOG moved it to the top of the forum. 
And I cannot delete this now, because I change my user name from "Andrey" to "Andrey Pashnin" :)

"Only user Andrey can delete this entry"

Hi,

I use some CSS for each elog to resize column correcly and it seems that current ELOG version 3.14 available from EPEL for EL7 has a problem (maybe others also).

The browser console displays an error when loading ELOG logbook page (french locale ):

La feuille de style https:/xxxxx.xxx.xx/elog/MCO/1130_171749_REUNION_20221130_Q01.jpgelog-mco.css n’a pas été chargée car son type MIME, « text/html », n’est pas « text/css ».

It seems ELOG server send the css link with enclosure path (https:/xxxxx.xxx.xx/elog/MCO/1130_171749_REUNION_20221130_Q01.jpg) + css file (elog-mco.css) ?!?

I tryed to rebuild the last source from git under EL7 but it fails with LDAP libs (C++ regression already reported in elog:forum/69478). :-(

Thanks for help.

Laurent

Update : i tryed with last git, w/o ldap support and it seems the problem is solved with CCS URL on same machine (just replace the elogd binary from EPEL by new one just build w/o LDAP support and fallback on File to login for testing).

So my problem is the error during build with LDAP auth (since using C++) :-(

...

+ cd elog-3-14
+ make USE_SSL=1 USE_LDAP=1 USE_KRB5=1 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml'
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -c -o mxml.o mxml/mxml.cxx
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -w -c -o crypt.o src/crypt.cxx
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -c -o strlcpy.o mxml/strlcpy.cxx
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -o elog src/elog.cxx mxml.o crypt.o strlcpy.o -lssl -lkrb5 -lldap -llber
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -w -c -o auth.o src/auth.cxx
src/auth.cxx: In function 'int auth_verify_password_ldap(LOGBOOK*, const char*, const char*, char*, int)':
src/auth.cxx:283:60: error: 'ldap_simple_bind_s' was not declared in this scope
    bind = ldap_simple_bind_s(ldap_ld, ldap_bindDN, password);
                                                            ^
src/auth.cxx:290:26: error: 'ldap_unbind' was not declared in this scope
       ldap_unbind(ldap_ld);
                          ^
src/auth.cxx:295:23: error: 'ldap_unbind' was not declared in this scope
    ldap_unbind(ldap_ld);
                       ^
src/auth.cxx: In function 'int ldap_adduser_file(LOGBOOK*, const char*, const char*, char*, int)':
src/auth.cxx:323:60: error: 'ldap_simple_bind_s' was not declared in this scope
    bind = ldap_simple_bind_s(ldap_ld, ldap_bindDN, password);
                                                            ^
src/auth.cxx:330:26: error: 'ldap_unbind' was not declared in this scope
       ldap_unbind(ldap_ld);
                          ^
src/auth.cxx:358:26: error: 'ldap_unbind' was not declared in this scope
       ldap_unbind(ldap_ld);
                          ^
src/auth.cxx:369:62: error: 'ldap_get_values' was not declared in this scope
          if((values = ldap_get_values(ldap_ld,entry,attribute)) != NULL ) {
                                                              ^
src/auth.cxx:378:35: error: 'ldap_value_free' was not declared in this scope
             ldap_value_free(values);
                                   ^
src/auth.cxx:386:23: error: 'ldap_unbind' was not declared in this scope
    ldap_unbind(ldap_ld);
                       ^
src/auth.cxx: In function 'int auth_verify_password(LOGBOOK*, const char*, const char*, char*, int)':
src/auth.cxx:593:73: error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
          if (get_user_line(lbs, user, NULL, NULL, NULL, NULL, NULL, NULL) == 2) {
                                                                         ^
In file included from src/auth.cxx:30:0:
src/elogd.h:282:5: error:   initializing argument 2 of 'int get_user_line(LOGBOOK*, char*, char*, char*, char*, BOOL*, time_t*, int*)' [-fpermissive]
 int get_user_line(LOGBOOK * lbs, char *user, char *password, char *full_name, char *email,
     ^
make: *** [auth.o] Error 1
error: Bad exit status from /home/il/jeanrigaudl/rpmbuild/tmp/rpm-tmp.cKJL45 (%build)

Updated :

1. from google (https://www.openldap.org/lists/openldap-technical/201104/msg00030.html), it seems it's necessary to add before "#include ldap.h" in src/auth.cxx

#define LDAP_DEPRECATED 1

2. A cast must be added to src/auth.cxx:593 as already done somewhere with C++ commit :

         if (get_user_line(lbs, (char *) user, NULL, NULL, NULL, NULL, NULL, NULL) == 2) {
 

-> elogd builds now with ldap :-) .

I installed elogd binary and i could login and the css url problem is gone.

Thanks to update auth.cxx (2 mods) and buildrpm (2 mods) in git (sorry, no pull request).

NB : PAM can not be activated under EL7 with same type of error. I disabled the feature as i do not use it.

+ cd elog-3-14
+ make USE_SSL=1 USE_PAM=1 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml'
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_PAM -c -o mxml.o mxml/mxml.cxx
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_PAM -w -c -o crypt.o src/crypt.cxx
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_PAM -c -o strlcpy.o mxml/strlcpy.cxx
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_PAM -o elog src/elog.cxx mxml.o crypt.o strlcpy.o -lssl -lpam -llber
c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_PAM -w -c -o auth.o src/auth.cxx
src/auth.cxx: In function 'int elog_conv(int, const pam_message**, pam_response**, void*)':
src/auth.cxx:452:59: error: invalid conversion from 'void*' to 'pam_response*' [-fpermissive]
    if((*resp = calloc(num_msg, sizeof(struct pam_response))) == NULL)
                                                           ^
src/auth.cxx:457:33: error: invalid conversion from 'void*' to 'const char*' [-fpermissive]
    if(!(resptok = strdup(my_data))) {
                                 ^
In file included from src/elogd.h:46:0,
                 from src/auth.cxx:30:
/usr/include/string.h:172:14: error:   initializing argument 1 of 'char* strdup(const char*)' [-fpermissive]
 extern char *strdup (const char *__s)
              ^
make: *** [auth.o] Error 1
error: Bad exit status from /home/il/jeanrigaudl/rpmbuild/tmp/rpm-tmp.V2LE4L (%build)
 

> elogd binary from EPEL

thank you for bringing this up to our attention. we recently went through this with debian and ubuntu. the elog package was severely out of date and 
did not include the security patches that went it right before covid started in the Winter of 2020.

the elogd package in EPEL7 is insecure and should not be used. (I see it is removed from EPEL8, EPEL9 and current Fedora).

I will have to contact EPEL maintainers to have it removed from EPEL7 (or at least to have it marked as "insecure, do not use").

https://dl.fedoraproject.org/pub/epel/7/SRPMS/Packages/e/elog-3.1.4-1.20190113git283534d97d5a.el7.src.rpm

https://packages.fedoraproject.org/pkgs/elog/elog/
https://packages.fedoraproject.org/pkgs/elog/elog/fedora-35.html
https://packages.fedoraproject.org/pkgs/elog/elog/epel-7.html

note in the changelog "Update to post-release snapshot of 3.1.4. - Fix several security issues."

K.O.

> > elogd binary from EPEL
> 
> thank you for bringing this up to our attention. we recently went through this with debian and ubuntu. the elog package was severely out of date and 
> did not include the security patches that went it right before covid started in the Winter of 2020.
> 
> the elogd package in EPEL7 is insecure and should not be used. (I see it is removed from EPEL8, EPEL9 and current Fedora).
> 
> I will have to contact EPEL maintainers to have it removed from EPEL7 (or at least to have it marked as "insecure, do not use").
> 
> https://dl.fedoraproject.org/pub/epel/7/SRPMS/Packages/e/elog-3.1.4-1.20190113git283534d97d5a.el7.src.rpm
> 
> https://packages.fedoraproject.org/pkgs/elog/elog/
> https://packages.fedoraproject.org/pkgs/elog/elog/fedora-35.html
> https://packages.fedoraproject.org/pkgs/elog/elog/epel-7.html
> 
> note in the changelog "Update to post-release snapshot of 3.1.4. - Fix several security issues."
> 
> K.O.


Good day, elog has never been retired in EPEL 7. It is still there
https://src.fedoraproject.org/rpms/elog/tree/epel7

I am pretty sure because I am a Fedora/RHEL package maintainer and a retired package should contain in its Git branch only a file named "dead.package"

Hi Stefan,

It seems buildrpm should be updated to take care of cpp files. Plz replace "cp <blahblah>.c ..." by "cp <blahblah>.cxx ..." .

Also, uncomment the hostname test witch activates all authentification options by default. It should be done by adding options as follow : buildrpm ver rel -ldap -ker ...

By default, i can not build elog with LDAP.

After that mods, rpms are builded under EL7 (w/o LDAP support which is not useful for me).

Bye

Laurent

We use our instance of ELOG as a operations log so that newest events are sorted at the top.

Sometimes we are also up front informed about planned maintenance, and i would be nice to could "pin" them at the top - before the sorting, so that operatores could have them in mind when starting a new shift. Have anyone found a way to solve this?

Kind Regards Finn

The way to do this is to ensure that the date of the entry is in the future.  As a hard -core linux (ab)user of elog, I create an entry, then dive into the yymmdda.log files, and edit it so that the date at the top of the entry is, for example, Sat, 31 Dec 2022 23:59:59.  Then, that entry will remain at the top of the listings until the New Year.  I do this very thing for the very same reason, i.e. to keep one entry at the top of the listings until after a certain date.

It may be that if you have "date of entry" field and sort by that, you could set the date of entry in the future.  I've not tried that.

The same effect could be done by adjusting the computer/server's date to the future, make the entry and then reset back to the present, but that may well be unpopular and impractical.  On a single computer, I have done this, although I then changed to editing the yymmdda.log file directly.