ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
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.
|
|
69802
|
Mon Jul 15 14:24:43 2024 |
| Michael | woegerbauer.micha@gmail.com | Question | Windows | 3.1.4 | Elog in HTML Title | 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. |
69801
|
Mon Jul 15 09:45:56 2024 |
| Enrico Gamberini | Hi Laureenrico.gamberini@cern.ch | Bug report | Linux | 3.1.5-20240226 | Re: broken http response when deployed on OpenShift | 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
|
|
|
|
69800
|
Fri Jul 12 17:39:53 2024 |
| David Pilgram | David.Pilgram@epost.org.uk | Info | Linux | 3.1.4 | Re: Extendable list of numeric items | Just to add some points for others who may find this of use in future.
The hard coded number of entries options or Moptions can have is 100. You can edit the code and recompile, but that would
not gain you many more before other problems concerning memory come in.
Options allow you to only select one from the list; Moptions allow multiple selections from the list.
As mentioned by Sebastian (previous poster) and in my suggestion. I imagined that by Wafer 1060 (say), no new work would be
being done on wafers 1001, ... 1010, so you could edit the config file and remove those (M)options. It does not remove these
wafer IDs from past records, simply that they can no longer be selected for new work to be recorded. In that way the
Moptions list remains short but allows for hundreds or thousands of WaferIDs, ON THE ASSUMPTION that say only 50 (and certainly
less than 100) are being worked on at any one time.
The numbers I chose here were random, it's more to highlight the principle rather than a prescription.
David.
> Just my 2 cents:
>
> There is a hardcoded limit how many entries the Option list can have. Without looking into the source, I assume the limit also exists for MOptions.
> If you want more, you have to recompile elog with the changed limit.
>
> We have used the normal Options attribute and a "Execute new"-script to alter the elog config for the Options list: to sort the list (5 last used entries on top, the rest alphabetical) and remove very old entries, which are not needed any more.
> Remark: if you change the elog.cfg, you have to tell elog to reload the cfg. e.g. using "killall -HUP elogd".
>
> Alternatively, you can add javascript code via a html file and the attributes "Top text" or "Bottom text" to manipulate the input fields on the client side.
>
> Both ways are a little bit hacky, but they work.
> Best wishes,
> Sebastian
>
> > Thanks for you help. This is almost it.
> >
> > The problem is that the items are options and not freely closable numbers. In the end, with your solution, it will show you all of the previously put IDs which will be 1000s of entries for us. I think I will just put a convention that we have to write the numbers spread with a comma in a string
> > field.
> >
> > Thanks.
> >
> > Best,
> >
> > Nick
> >
> >
> > > I have replied to this entry, because, for some reason I don't understand, if I reply to your latest entry, I am
> > > automatically logged out. I tried this multiple times, and also on many other entries and had no issues other than
> > > entry 69787 - any reason for this, Stefan?
> > >
> > > Anyway, what about MOptions? That appears to do what your example, and needs two lines in elog.cfg file:
> > >
> > > Moptions WaferID = 1001, 1002, 1003, 1004, 1005
> > > Extendable Options = WaferID
> > >
> > > I've done a couple of quick tests on a test logbook I keep for such experimentation, and it appears to do all
> > > you have asked of it. I added a new option 1006. However, I found that one has to add that new one on its own,
> > > let the entry become proper, and then edit the entry to add the other, existing, values. If you tick entries and
> > > also add a new one, then your new entry is all those listed on their own, that is you would get and new entry
> > > in the config file such as "1002 | 1004 | 1006", rather than just 1006
> > >
> > > This is probably an result of an unexpected use of Moptions and extendable options, rather than a bug per se.
> > >
> > > > Hey,
> > > >
> > > > thanks for your answer. I completely get your point. However, I think my question as not precise enough.
> > > >
> > > > I would like to have a numeric input, but many at the same time. When I make a new post, I would like to have an attribute 'wafer_IDs' that specifies the list of wafers this process has been performed with. So for a single post I would like to have a list like this:
> > > >
> > > > wafer_IDs = numeric value, numeric value, numeric value, extendable
> > > >
> > > > Note: I am not referring here to the option. The numeric values are freely chooses numbers, the only this that varies from post to post is the number of numeric values put.
> > > >
> > > > Let me make an example (If the attribute were a string this would be the equivalent):
> > > >
> > > > 1st post: A process that was run with 3 wafers (ID: 1000, ID: 1001 and ID: 1002):
> > > > wafer IDs = 1000, 1001, 1002
> > > >
> > > > 2nd post: A process that is run with 2 wafers (ID: 1000 and ID: 1002):
> > > > wafer IDs = 1000, 1002
> > > >
> > > > The string solves the issue, but is not as nice as having directly a list of integers.
> > > >
> > > > Thanks for your help!
> > > >
> > > > Best,
> > > >
> > > > Nick |
69799
|
Fri Jul 12 16:51:44 2024 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Info | Linux | 3.1.4 | Re: Extendable list of numeric items | Just my 2 cents:
There is a hardcoded limit how many entries the Option list can have. Without looking into the source, I assume the limit also exists for MOptions.
If you want more, you have to recompile elog with the changed limit.
We have used the normal Options attribute and a "Execute new"-script to alter the elog config for the Options list: to sort the list (5 last used entries on top, the rest alphabetical) and remove very old entries, which are not needed any more.
Remark: if you change the elog.cfg, you have to tell elog to reload the cfg. e.g. using "killall -HUP elogd".
Alternatively, you can add javascript code via a html file and the attributes "Top text" or "Bottom text" to manipulate the input fields on the client side.
Both ways are a little bit hacky, but they work.
Best wishes,
Sebastian
> Thanks for you help. This is almost it.
>
> The problem is that the items are options and not freely closable numbers. In the end, with your solution, it will show you all of the previously put IDs which will be 1000s of entries for us. I think I will just put a convention that we have to write the numbers spread with a comma in a string
> field.
>
> Thanks.
>
> Best,
>
> Nick
>
>
> > I have replied to this entry, because, for some reason I don't understand, if I reply to your latest entry, I am
> > automatically logged out. I tried this multiple times, and also on many other entries and had no issues other than
> > entry 69787 - any reason for this, Stefan?
> >
> > Anyway, what about MOptions? That appears to do what your example, and needs two lines in elog.cfg file:
> >
> > Moptions WaferID = 1001, 1002, 1003, 1004, 1005
> > Extendable Options = WaferID
> >
> > I've done a couple of quick tests on a test logbook I keep for such experimentation, and it appears to do all
> > you have asked of it. I added a new option 1006. However, I found that one has to add that new one on its own,
> > let the entry become proper, and then edit the entry to add the other, existing, values. If you tick entries and
> > also add a new one, then your new entry is all those listed on their own, that is you would get and new entry
> > in the config file such as "1002 | 1004 | 1006", rather than just 1006
> >
> > This is probably an result of an unexpected use of Moptions and extendable options, rather than a bug per se.
> >
> > > Hey,
> > >
> > > thanks for your answer. I completely get your point. However, I think my question as not precise enough.
> > >
> > > I would like to have a numeric input, but many at the same time. When I make a new post, I would like to have an attribute 'wafer_IDs' that specifies the list of wafers this process has been performed with. So for a single post I would like to have a list like this:
> > >
> > > wafer_IDs = numeric value, numeric value, numeric value, extendable
> > >
> > > Note: I am not referring here to the option. The numeric values are freely chooses numbers, the only this that varies from post to post is the number of numeric values put.
> > >
> > > Let me make an example (If the attribute were a string this would be the equivalent):
> > >
> > > 1st post: A process that was run with 3 wafers (ID: 1000, ID: 1001 and ID: 1002):
> > > wafer IDs = 1000, 1001, 1002
> > >
> > > 2nd post: A process that is run with 2 wafers (ID: 1000 and ID: 1002):
> > > wafer IDs = 1000, 1002
> > >
> > > The string solves the issue, but is not as nice as having directly a list of integers.
> > >
> > > Thanks for your help!
> > >
> > > Best,
> > >
> > > Nick |
|