| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69811
|
Fri Jul 26 12:52:54 2024 |
 | Carl Unsworth | carl.unsworth@stfc.ac.uk | Bug report | Linux | V3.1.5-23df00d | Old attachments erroneously appearing on new Elog entries. | Hi, I'm not sure if this is an Elog bug, something wrong in my configuration/database.
When I create a new article on Elog it always shows an attachment from one of the first entries ever made to this log book made. This is in addition to any attachments which were actually added during article creation.
I just made an example entry to demonstrate. First attachment here shows how the entry looks in the GUI, it has an attached text file called "jail.local", 2nd attachment is how that entry looks in the database file - no attachment.
Does anyone have any idea what's happening? |
| Attachment 1: Screenshot_from_2024-07-26_11-46-44.png
|
|
| Attachment 2: Screenshot_from_2024-07-26_11-47-58.png
|
|
|
69809
|
Wed Jul 24 17:21:45 2024 |
 | Aled Isaac | c.a.isaac@swnsea.ac.uk | Info | Windows | ELOG V3.1.4-a04 | Re: Elog/ImageMagick under windows 11 | I've managed to get it working and the problem wasn't what I thought it was. It turns out that ImageMagick v7 doesn't have a "convert.exe" program in the windows version due to some conflict with a disk conversion utility. The "convert.exe" has been replaced with a "magick.exe" and so I made a CONVERT.BAT script within the elog folder with content "magick %*". This workaround appears to have solved the problem.
| Aled Isaac wrote: |
|
I was wondering if anyone would be able to assist me in getting the ImageMagick/figure scaling working on an elog running under windows 11 (Microsoft Windows Version 22H2 (OS Build 22621.3880)). I've followed the installation instructions and checked that $PATH contains the directory for both ImageMagick and GSS. In a 'command prompt' window, when I execute "identify -version" from any directory I get the response:
Version: ImageMagick 7.1.1-35 Q16-HDRI x64 d775d2a:20240714 https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Channel-masks(64-bit) Cipher DPC HDRI Modules OpenCL OpenMP(2.0)
Delegates (built-in): bzlib cairo flif freetype gslib heic jng jp2 jpeg jxl lcms lqr lzma openexr pangocairo png ps raqm raw rsvg tiff webp xml zip zlib
Compiler: Visual Studio 2022 (194033811)
which I believe is correct. I've looked through the source-code for the elog and I believe that upon initialisation elogd is looking for a response containing "ImageMagick" somewhere in the response [image_magick_exist = (strstr(str, "ImageMagick") != NULL);] so I'm not sure I understand why this isn't being satisfied. When I run elogd I get the statement "ImageMagick NOT detected. Image scaling will not work.".
I have the feeling that this is some security restriction in windows 11, so was wondering if anyone had seen this problem before and knew of a solution.
Many Thanks
|
|
|
69808
|
Mon Jul 22 16:30:04 2024 |
| André | andre.althaus@tu-dortmund.de | Bug report | Linux | 3.1.4-3 | Re: 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
|
|
|
|
69807
|
Mon Jul 22 16:17:55 2024 |
| André | andre.althaus@tu-dortmund.de | Bug report | All | 3.1.5 | HTTP 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. |
|
69806
|
Thu Jul 18 11:38:01 2024 |
 | Aled Isaac | c.a.isaac@swnsea.ac.uk | Question | Windows | ELOG V3.1.4-a04 | Elog/ImageMagick under windows 11 | I was wondering if anyone would be able to assist me in getting the ImageMagick/figure scaling working on an elog running under windows 11 (Microsoft Windows Version 22H2 (OS Build 22621.3880)). I've followed the installation instructions and checked that $PATH contains the directory for both ImageMagick and GSS. In a 'command prompt' window, when I execute "identify -version" from any directory I get the response:
Version: ImageMagick 7.1.1-35 Q16-HDRI x64 d775d2a:20240714 https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Channel-masks(64-bit) Cipher DPC HDRI Modules OpenCL OpenMP(2.0)
Delegates (built-in): bzlib cairo flif freetype gslib heic jng jp2 jpeg jxl lcms lqr lzma openexr pangocairo png ps raqm raw rsvg tiff webp xml zip zlib
Compiler: Visual Studio 2022 (194033811)
which I believe is correct. I've looked through the source-code for the elog and I believe that upon initialisation elogd is looking for a response containing "ImageMagick" somewhere in the response [image_magick_exist = (strstr(str, "ImageMagick") != NULL);] so I'm not sure I understand why this isn't being satisfied. When I run elogd I get the statement "ImageMagick NOT detected. Image scaling will not work.".
I have the feeling that this is some security restriction in windows 11, so was wondering if anyone had seen this problem before and knew of a solution.
Many Thanks
|
|
69805
|
Tue Jul 16 00:45:08 2024 |
| Laurent Jean-Rigaud | lollspam@free.fr | Bug report | Linux | 3.1.5-20240226 | Re: broken http response when deployed on OpenShift | Also, you have the option to rebuild RPM from SRPMS or SOURCES via ELOG buildrpm script.
You will need to install rpmbuild tools...
Options (ldap, kb5, etc) can be set from options or by editing defaults.
| Laurent Jean-Rigaud wrote: |
|
Enrico,
When using RPM in OpenShift, I guess all the RPM dependencies are correctly installed.
FYI, I met a problem with elogd docker built with alpine Linux image and running on Synology NAS (x86_64). The ImageMagick dependencies libs provided by alpine for X86_64 are optimized for better CPU than mine with AVX2 (or something like that), and elogd failed to save a log with any enclosure (core exit, bad instruction), as some thumbnails are generated while saving.
As I didn't find any easy workaround w/o rebuilding all IM libs, so I switch to Debian images more conservative in CPU optimization, but bigger :-( before to switch to minideb that's run fine in my case.
It's not easy to debug in container w/o making one specially for that, so you should try to build a docker based on alma9 image, compiling elogd from sources (you can follow https://github.com/loll31/elog-ldap for the process).
Good luck
NB : The ldd result from my minideb Docker :
root@9ac6063e87bf:/# ldd -v /usr/local/sbin/elogd
linux-vdso.so.1 (0x00007ffd0e794000)
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007fc00ac35000)
libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 (0x00007fc00abd6000)
liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0 (0x00007fc00abc6000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc00a9ac000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc00a98c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc00a7a9000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fc00a328000)
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fc00a30b000)
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fc00a0ef000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc00a010000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc00f959000)
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fc009eda000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007fc009ea9000)
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007fc009cf3000)
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fc009cde000)
libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007fc009c90000)
libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007fc009c47000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fc009bc4000)
libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007fc009bb8000)
| Enrico Gamberini wrote: |
|
Hi Laurent,
Thanks, good point! I'm building a vanilla version (no extra options enabled as I'm using Webserver authentication).
3.15 RPM:
-rwxr-xr-x. 1 elog elog 1574768 Feb 26 17:29 elogd
bash-5.1$ ldd /usr/local/sbin/elogd
linux-vdso.so.1 (0x00007fff215f7000)
libssl.so.3 => /lib64/libssl.so.3 (0x00007feff74c6000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007feff73eb000)
libldap.so.2 => /lib64/libldap.so.2 (0x00007feff7384000)
liblber.so.2 => /lib64/liblber.so.2 (0x00007feff7372000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007feff7360000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007feff7139000)
libm.so.6 => /lib64/libm.so.6 (0x00007feff705c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007feff7041000)
libc.so.6 => /lib64/libc.so.6 (0x00007feff6e38000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007feff6a07000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007feff69ee000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007feff69e7000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007feff69d4000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007feff69cd000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007feff69b9000)
libevent-2.1.so.7 => /lib64/libevent-2.1.so.7 (0x00007feff6960000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007feff6940000)
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007feff6912000)
libeconf.so.0 => /lib64/libeconf.so.0 (0x00007feff6905000)
/lib64/ld-linux-x86-64.so.2 (0x00007feff7572000)
libz.so.1 => /lib64/libz.so.1 (0x00007feff68eb000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007feff68be000)
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007feff6884000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007feff682d000)
libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007feff6822000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007feff6786000)
3.15 source vanilla build:
-rwxr-xr-x. 1 root root 1503896 Jul 15 09:31 elogd
bash-5.1$ ldd elogd
linux-vdso.so.1 (0x00007fff60bbf000)
libssl.so.3 => /lib64/libssl.so.3 (0x00007f8f83e44000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8f83c1b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8f83b40000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8f83b25000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8f8391c000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f8f834e9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8f83ef0000)
libz.so.1 => /lib64/libz.so.1 (0x00007f8f834cd000)
Best,
Enrico
| Laurent Jean-Rigaud wrote: |
|
Hey Enrico,
Do you activate also all options with your build ? (pam/ldap/kb5/ssl)
Can you compare ldd command results on elogd binaries builded by yourself and the one from RPM ?
$ ldd /path/to/elogd
Also, size of both elogd files.
Regards
| Enrico Gamberini wrote: |
|
Sorry for posting again but something else came up.
Actually, building from source (elog-3.1.5-1.tar.gz) works just fine on OpenShift too.
The problem described below only happens when installing the packaged binary elog-3.1.5-20240226.el9.x86_64.rpm.
Best,
Enrico
| Enrico Gamberini wrote: |
|
Hello!
We're setting up ELOG on OpenShift. ELOG is installed on a Alma Linux 9 image. The container and the elog demo works fine executing the docker image locally.
When deployed on OpenShift, we get a weird response, that results in a 502 Bad Gateway. The broken response looks like:
# curl -v -H 'X-Forwarded-User: enrico.gamberini@cern.ch' https://psi-elog-container2-elisa-epdtdi.app.cern.ch/demo/
<html>redir</html>
HTTP/1.1 200 Document follows
HTTP/1.1 200 Document follows
Server: ELOG HTTP 3.1.5-23df00d
Content-Type: text/html;charset=ISO-8859-1
Set-Cookie: elmode=Summary; path=/demo; expires=Friday, 07-Dec-35 06:30:26 GMT;
Pragma: no-cache
Cache-control: private, max-age=0, no-cache, no-store
Notice the HTML tag before the HTTP header, as well the duplicate HTTP header.
I understand that it might be difficult to reproduce, but any input would be very welcome!
Thanks!
Best,
Enrico
|
|
|
|
|
|
|
69804
|
Tue Jul 16 00:15:12 2024 |
| Laurent Jean-Rigaud | lollspam@free.fr | Bug report | Linux | 3.1.5-20240226 | Re: broken http response when deployed on OpenShift | Enrico,
When using RPM in OpenShift, I guess all the RPM dependencies are correctly installed.
FYI, I met a problem with elogd docker built with alpine Linux image and running on Synology NAS (x86_64). The ImageMagick dependencies libs provided by alpine for X86_64 are optimized for better CPU than mine with AVX2 (or something like that), and elogd failed to save a log with any enclosure (core exit, bad instruction), as some thumbnails are generated while saving.
As I didn't find any easy workaround w/o rebuilding all IM libs, so I switch to Debian images more conservative in CPU optimization, but bigger :-( before to switch to minideb that's run fine in my case.
It's not easy to debug in container w/o making one specially for that, so you should try to build a docker based on alma9 image, compiling elogd from sources (you can follow https://github.com/loll31/elog-ldap for the process).
Good luck
NB : The ldd result from my minideb Docker :
root@9ac6063e87bf:/# ldd -v /usr/local/sbin/elogd
linux-vdso.so.1 (0x00007ffd0e794000)
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007fc00ac35000)
libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 (0x00007fc00abd6000)
liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0 (0x00007fc00abc6000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc00a9ac000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc00a98c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc00a7a9000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fc00a328000)
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fc00a30b000)
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fc00a0ef000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc00a010000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc00f959000)
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fc009eda000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007fc009ea9000)
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007fc009cf3000)
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fc009cde000)
libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007fc009c90000)
libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007fc009c47000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fc009bc4000)
libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007fc009bb8000)
| Enrico Gamberini wrote: |
|
Hi Laurent,
Thanks, good point! I'm building a vanilla version (no extra options enabled as I'm using Webserver authentication).
3.15 RPM:
-rwxr-xr-x. 1 elog elog 1574768 Feb 26 17:29 elogd
bash-5.1$ ldd /usr/local/sbin/elogd
linux-vdso.so.1 (0x00007fff215f7000)
libssl.so.3 => /lib64/libssl.so.3 (0x00007feff74c6000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007feff73eb000)
libldap.so.2 => /lib64/libldap.so.2 (0x00007feff7384000)
liblber.so.2 => /lib64/liblber.so.2 (0x00007feff7372000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007feff7360000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007feff7139000)
libm.so.6 => /lib64/libm.so.6 (0x00007feff705c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007feff7041000)
libc.so.6 => /lib64/libc.so.6 (0x00007feff6e38000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007feff6a07000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007feff69ee000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007feff69e7000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007feff69d4000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007feff69cd000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007feff69b9000)
libevent-2.1.so.7 => /lib64/libevent-2.1.so.7 (0x00007feff6960000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007feff6940000)
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007feff6912000)
libeconf.so.0 => /lib64/libeconf.so.0 (0x00007feff6905000)
/lib64/ld-linux-x86-64.so.2 (0x00007feff7572000)
libz.so.1 => /lib64/libz.so.1 (0x00007feff68eb000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007feff68be000)
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007feff6884000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007feff682d000)
libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007feff6822000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007feff6786000)
3.15 source vanilla build:
-rwxr-xr-x. 1 root root 1503896 Jul 15 09:31 elogd
bash-5.1$ ldd elogd
linux-vdso.so.1 (0x00007fff60bbf000)
libssl.so.3 => /lib64/libssl.so.3 (0x00007f8f83e44000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8f83c1b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8f83b40000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8f83b25000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8f8391c000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f8f834e9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8f83ef0000)
libz.so.1 => /lib64/libz.so.1 (0x00007f8f834cd000)
Best,
Enrico
| Laurent Jean-Rigaud wrote: |
|
Hey Enrico,
Do you activate also all options with your build ? (pam/ldap/kb5/ssl)
Can you compare ldd command results on elogd binaries builded by yourself and the one from RPM ?
$ ldd /path/to/elogd
Also, size of both elogd files.
Regards
| Enrico Gamberini wrote: |
|
Sorry for posting again but something else came up.
Actually, building from source (elog-3.1.5-1.tar.gz) works just fine on OpenShift too.
The problem described below only happens when installing the packaged binary elog-3.1.5-20240226.el9.x86_64.rpm.
Best,
Enrico
| Enrico Gamberini wrote: |
|
Hello!
We're setting up ELOG on OpenShift. ELOG is installed on a Alma Linux 9 image. The container and the elog demo works fine executing the docker image locally.
When deployed on OpenShift, we get a weird response, that results in a 502 Bad Gateway. The broken response looks like:
# curl -v -H 'X-Forwarded-User: enrico.gamberini@cern.ch' https://psi-elog-container2-elisa-epdtdi.app.cern.ch/demo/
<html>redir</html>
HTTP/1.1 200 Document follows
HTTP/1.1 200 Document follows
Server: ELOG HTTP 3.1.5-23df00d
Content-Type: text/html;charset=ISO-8859-1
Set-Cookie: elmode=Summary; path=/demo; expires=Friday, 07-Dec-35 06:30:26 GMT;
Pragma: no-cache
Cache-control: private, max-age=0, no-cache, no-store
Notice the HTML tag before the HTTP header, as well the duplicate HTTP header.
I understand that it might be difficult to reproduce, but any input would be very welcome!
Thanks!
Best,
Enrico
|
|
|
|
|
|
69803
|
Mon Jul 15 14:35:40 2024 |
| Stefan Ritt | You stefan.ritt@psi.ch | Question | Windows | 3.1.4 | Re: Elog in HTML Title | You can change the title for the standard page with 'Page title = ...' and for the list page with 'List Page title = ...', but unfortunately not for all pages (such as the search mask).
Stefan
| Michael wrote: |
|
Hi,
is it possible to change the name ELOG from all HTML titles.
E.g. find/search. If you click on find/search the browser/html tag/title is 'ELOG search'. Is it possible to change this to 'xxx search' and how.
|
|
|