| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
65914
|
Fri Jun 27 18:31:08 2008 |
 | George Chisholm | george.chisholm@terasengas.com | Question | Windows | 2.7.4 | Re: browse for hyperlink target? |
| Stefan Ritt wrote: |
|
| George Chisholm wrote: |
|
Just upgraded to v2.7.4 and really like the new editor but I need to be able to browse for the correct file when inserting a hyperlink. I looked into CKfinder but can't see how to use this with ELOG. Can anyone help? We have been using ELOG in our control center for about a year and it is working out great!
|
CKfinder is a tool to browse the server, not the client where the web browser is running if I understand correctly. ELOG only supports attachment and inline images residing on the client side, so you browse with the file selector of your web browser. Or did I understand you incorrectly?
|
Thanks for the reply Stefan and thanks for making this program available - where can we send a donation?
When I click 'InsertLink' in the FCKeditor I get an 'Explorer User Promp' popup asking me to enter the name of the hyperlink. After I enter the name I get 'Enter URL of hyperlink'. Typically I want to link to a file on a mapped drive but I would prefer to browse to the file location and select the file rather than type it in. |
|
65915
|
Sat Jun 28 10:10:54 2008 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.7.4 | Re: browse for hyperlink target? |
|
George Chisholm wrote:
|
|
| Stefan Ritt wrote: |
|
| George Chisholm wrote: |
|
Just upgraded to v2.7.4 and really like the new editor but I need to be able to browse for the correct file when inserting a hyperlink. I looked into CKfinder but can't see how to use this with ELOG. Can anyone help? We have been using ELOG in our control center for about a year and it is working out great!
|
CKfinder is a tool to browse the server, not the client where the web browser is running if I understand correctly. ELOG only supports attachment and inline images residing on the client side, so you browse with the file selector of your web browser. Or did I understand you incorrectly?
|
Thanks for the reply Stefan and thanks for making this program available - where can we send a donation?
When I click 'InsertLink' in the FCKeditor I get an 'Explorer User Promp' popup asking me to enter the name of the hyperlink. After I enter the name I get 'Enter URL of hyperlink'. Typically I want to link to a file on a mapped drive but I would prefer to browse to the file location and select the file rather than type it in.
|
You can donate here by clicking the donate link at the ELOG page.
If you want to attach a file from a mapped drive you click on the "Browse..." button at the bottom of the ELOG page:
|
|
69796
|
Thu Jul 11 15:25:19 2024 |
| Enrico Gamberini | enrico.gamberini@cern.ch | Bug report | Linux | 3.1.5-20240226 | Re: broken http response when deployed on OpenShift | 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
|
|
|
69797
|
Thu Jul 11 19:15:39 2024 |
| Laurent Jean-Rigaud | lollspam@free.fr | Bug report | Linux | 3.1.5-20240226 | Re: broken http response when deployed on OpenShift | 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
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
|
967
|
Wed Mar 2 15:19:56 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | r1.571 | Re: boundary problem with Type lists display | > using:
> Display mode = threaded
> List display = Subject, Type, Author, Date
>
> in the config file (omitting "ID" then) rise the bug
>
> ie, an unneeded "," is displayed after the "supposed to be printed" ID
Fixed in CVS revision 1.574 |
|