broken http response when deployed on OpenShift, posted by Enrico Gamberini on Wed Jul 10 17:43:07 2024
|
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 |
Re: broken http response when deployed on OpenShift, posted by Enrico Gamberini on Thu Jul 11 15:25:19 2024
|
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
|
|
|
Re: broken http response when deployed on OpenShift, posted by Laurent Jean-Rigaud on Thu Jul 11 19:15:39 2024
|
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
|
|
|
|
Re: broken http response when deployed on OpenShift, posted by Enrico Gamberini on Mon Jul 15 09:45:56 2024
|
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
|
|
|
|
|
Re: broken http response when deployed on OpenShift, posted by Laurent Jean-Rigaud on Tue Jul 16 00:15:12 2024
|
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
|
|
|
|
|
|
Re: broken http response when deployed on OpenShift, posted by Laurent Jean-Rigaud on Tue Jul 16 00:45:08 2024
|
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
|
|
|
|
|
|
|
Elog in HTML Title, posted by Michael on Mon Jul 15 14:24:43 2024
|
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. |
|
Re: Elog in HTML Title, posted by Stefan Ritt on Mon Jul 15 14:35:40 2024
|
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.
|
|
|
Extendable list of numeric items, posted by Nick Sauerwein on Mon Apr 8 15:46:49 2024
|
Hey eloggers,
I am setting up an ELOG to log the cleanroom fabrication in our startup (Luxtelligence SA). The fabrication is structured in different process steps that are performed by several wafers at the same time (each wafer as an ID).
I am looking for an possibility to put a list of several integers as one of the attributes.
Here an example:
Attributes = Batch ID, Wafer IDs
Type Batch ID = numeric
Type Wafer IDs = extendable list of numeric values
Does something like this exsist?
Thanks in advance for your help. |
|
Re: Extendable list of numeric items, posted by John Kelly on Mon Apr 8 17:08:11 2024
|
Hi Nick,
If I understand your question correctly maybe this might help:
Search for 'attribute' and you will find this:
"some attributes may be pre-filled from system variables (like your user name). Pre-filled attributes may be still editable or read-only (like the entry creation date.
Attributes may be text fields (limited to 100 characters), list-boxes (max. 100 values), or check-boxes. There is also a special type of attribute where several values are listed on a line with check-boxes, and you can check as many values as needed."
I guess this above is like creating an attribute field, that has attribute names. I *thought* there was a way to leave attributes open where users could create their own 'attribute' names, but the information above is all of what I remember from my past in depth work with Elog.
John
| Nick Sauerwein wrote: |
|
Hey eloggers,
I am setting up an ELOG to log the cleanroom fabrication in our startup (Luxtelligence SA). The fabrication is structured in different process steps that are performed by several wafers at the same time (each wafer as an ID).
I am looking for an possibility to put a list of several integers as one of the attributes.
Here an example:
Attributes = Batch ID, Wafer IDs
Type Batch ID = numeric
Type Wafer IDs = extendable list of numeric values
Does something like this exsist?
Thanks in advance for your help.
|
|
|
Re: Extendable list of numeric items, posted by Nick Sauerwein on Mon Apr 8 17:23:00 2024
|
Hi John,
thanks for the info =). Do you known whether there is an example of how to use the list-boxes attributes?
Best,
Nick
| John Kelly wrote: |
|
Hi Nick,
If I understand your question correctly maybe this might help:
Search for 'attribute' and you will find this:
"some attributes may be pre-filled from system variables (like your user name). Pre-filled attributes may be still editable or read-only (like the entry creation date.
Attributes may be text fields (limited to 100 characters), list-boxes (max. 100 values), or check-boxes. There is also a special type of attribute where several values are listed on a line with check-boxes, and you can check as many values as needed."
I guess this above is like creating an attribute field, that has attribute names. I *thought* there was a way to leave attributes open where users could create their own 'attribute' names, but the information above is all of what I remember from my past in depth work with Elog.
John
| Nick Sauerwein wrote: |
|
Hey eloggers,
I am setting up an ELOG to log the cleanroom fabrication in our startup (Luxtelligence SA). The fabrication is structured in different process steps that are performed by several wafers at the same time (each wafer as an ID).
I am looking for an possibility to put a list of several integers as one of the attributes.
Here an example:
Attributes = Batch ID, Wafer IDs
Type Batch ID = numeric
Type Wafer IDs = extendable list of numeric values
Does something like this exsist?
Thanks in advance for your help.
|
|
|
|
Re: Extendable list of numeric items, posted by Konstantin Olchanski on Tue Apr 9 04:46:36 2024
|
I think what you want already exists, for example, when I reply to this message, there is this "Category" selection box with predefined answers
"Info", "Bug report", etc. For your case, replace "Category" with "Wafer type ID", replace "Info" with "1", "Bug report" with "2", etc. You numeric
values will be strings containing numbers "1", "2", etc. That works for you? K.O. |
|
Re: Extendable list of numeric items, posted by Nick Sauerwein on Tue Apr 9 09:25:01 2024
|
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 |
|
Re: Extendable list of numeric items, posted by Nick Sauerwein on Fri Apr 19 12:30:52 2024
|
Hey eloggers,
does anyone have an answer to this question?
Thanks for the help.
Best,
Nick
> 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 |
Re: Extendable list of numeric items, posted by David Pilgram on Sat Apr 20 18:47:37 2024
|
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 |
|
Re: Extendable list of numeric items, posted by Nick Sauerwein on Fri Jul 12 16:30:02 2024
|
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 |
|
Re: Extendable list of numeric items, posted by Sebastian Schenk on Fri Jul 12 16:51:44 2024
|
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 |
|
Re: Extendable list of numeric items, posted by David Pilgram on Fri Jul 12 17:39:53 2024
|
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 |
|
, posted by sam wells on Mon May 20 11:54:37 2024
|
| |
|
elog sprintf() buffer overflows on ubuntu-22, posted by Konstantin Olchanski on Wed May 15 01:07:12 2024
|
I get the following compiler warnings about sprintf() buffer overflows. I suggest sprintf() should be replaced by std::string msprintf() from
midas. K.O.
iris00:~/packages> git clone https://bitbucket.org/ritt/elog --recursive
Cloning into 'elog'...
remote: Enumerating objects: 18297, done.
remote: Counting objects: 100% (18297/18297), done.
remote: Compressing objects: 100% (7710/7710), done.
remote: Total 18297 (delta 11462), reused 16637 (delta 10243), pack-reused 0 (from 0)
Receiving objects: 100% (18297/18297), 14.56 MiB | 17.14 MiB/s, done.
Resolving deltas: 100% (11462/11462), done.
Submodule 'mxml' (https://bitbucket.org/tmidas/mxml) registered for path 'mxml'
Cloning into '/home/iris/packages/elog/mxml'...
remote: Enumerating objects: 356, done.
remote: Counting objects: 100% (356/356), done.
remote: Compressing objects: 100% (242/242), done.
remote: Total 356 (delta 162), reused 265 (delta 112), pack-reused 0 (from 0)
Receiving objects: 100% (356/356), 85.65 KiB | 10.71 MiB/s, done.
Resolving deltas: 100% (162/162), done.
Submodule path 'mxml': checked out '4d4b4cf17bec323a76b8a87605efec6a4822bebf'
iris00:~/packages> cd elo
elog/ elog-2012/
iris00:~/packages> cd elog
iris00:~/packages/elog> make
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -c -o mxml.o mxml/mxml.cxx
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -w -c -o crypt.o
src/crypt.cxx
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -c -o strlcpy.o
mxml/strlcpy.cxx
type git &> /dev/null; if [ $? -eq 1 ]; then REV="unknown" ;else REV=`git log -n 1 --pretty=format:"%ad - %h"`; fi; echo \#define GIT_REVISION
\"$REV\" > src/git-revision.h
git is /bin/git
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -o elog src/elog.cxx
mxml.o crypt.o strlcpy.o -lssl
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -w -c -o auth.o
src/auth.cxx
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -o elogd src/elogd.cxx
auth.o mxml.o crypt.o strlcpy.o -lssl
src/elogd.cxx: In function ‘int el_submit(LOGBOOK*, int, BOOL, const char*, char (*)[1500], char (*)[1500], int, const char*, const char*, const
char*, const char*, const char (*)[256], BOOL, const char*, const char*)’:
src/elogd.cxx:4960:47: warning: ‘%s’ directive writing up to 149999 bytes into a region of size between 100103 and 250102 [-Wformat-overflow=]
4960 | sprintf(message + strlen(message), "%s: %s\n", attr_name[i], attrib[i]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 4 and 300002 bytes into a destination of size
250104
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx: In function ‘void show_edit_form(LOGBOOK*, int, BOOL, BOOL, BOOL, BOOL, BOOL, BOOL)’:
src/elogd.cxx:9659:28: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3993 [-Wformat-overflow=]
9659 | sprintf(str, "Preset %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 8 and 150007 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9680:43: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3978 [-Wformat-overflow=]
9680 | sprintf(str, "Preset on first reply %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 23 and 150022 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9701:37: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3984 [-Wformat-overflow=]
9701 | sprintf(str, "Preset on reply %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 17 and 150016 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9701:37: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3984 [-Wformat-overflow=]
9701 | sprintf(str, "Preset on reply %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 17 and 150016 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9701:37: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3984 [-Wformat-overflow=]
9701 | sprintf(str, "Preset on reply %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 17 and 150016 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9701:37: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3984 [-Wformat-overflow=]
9701 | sprintf(str, "Preset on reply %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 17 and 150016 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9721:36: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3985 [-Wformat-overflow=]
9721 | sprintf(str, "Preset on edit %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 16 and 150015 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9741:41: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3980 [-Wformat-overflow=]
9741 | sprintf(str, "Preset on duplicate %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 21 and 150020 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9762:22: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3999 [-Wformat-overflow=]
9762 | sprintf(str, "p%s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 2 and 150001 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9780:31: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3993 [-Wformat-overflow=]
9780 | sprintf(str, "Preset %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 8 and 150007 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9801:40: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3984 [-Wformat-overflow=]
9801 | sprintf(str, "Preset on reply %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 17 and 150016 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:9821:44: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 3980 [-Wformat-overflow=]
9821 | sprintf(str, "Preset on duplicate %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 21 and 150020 bytes into a destination of size
4000
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx: In function ‘void show_elog_list(LOGBOOK*, int, int, int, BOOL, char*)’:
src/elogd.cxx:20448:43: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1587 [-Wformat-overflow=]
20448 | sprintf(str, "Icon comment %s", attrib[i]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 14 and 150013 bytes into a destination of size
1600
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:20495:33: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1600 [-Wformat-overflow=]
20495 | sprintf(str, "%s_%d", attr_list[i], j);
| ^~
src/elogd.cxx:20495:32: note: directive argument in the range [0, 99]
20495 | sprintf(str, "%s_%d", attr_list[i], j);
| ^~~~~~~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 3 and 150003 bytes into a destination of size
1600
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:20459:33: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1600 [-Wformat-overflow=]
20459 | sprintf(str, "%s_%d", attr_list[i], j);
| ^~
src/elogd.cxx:20459:32: note: directive argument in the range [0, 99]
20459 | sprintf(str, "%s_%d", attr_list[i], j);
| ^~~~~~~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 3 and 150003 bytes into a destination of size
1600
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:21041:30: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1600 [-Wformat-overflow=]
21041 | sprintf(str, "%s_%d", attr_list[i], j);
| ^~
src/elogd.cxx:21041:29: note: directive argument in the range [0, 99]
21041 | sprintf(str, "%s_%d", attr_list[i], j);
| ^~~~~~~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 3 and 150003 bytes into a destination of size
1600
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:21527:45: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1588 [-Wformat-overflow=]
21527 | sprintf(str, "Time format %s", attr_list[i]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 13 and 150012 bytes into a destination of size
1600
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx:21512:45: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1588 [-Wformat-overflow=]
21512 | sprintf(str, "Date format %s", attr_list[i]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 13 and 150012 bytes into a destination of size
1600
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
src/elogd.cxx: In function ‘void submit_elog(LOGBOOK*)’:
src/elogd.cxx:23282:38: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 2034 [-Wformat-overflow=]
23282 | sprintf(str, "Subst on edit %s", attr_list[index]);
| ^~
In file included from /usr/include/stdio.h:894,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 15 and 150014 bytes into a destination of size
2048
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -o elconv src/elconv.cxx -
lssl
iris00:~/packages/elog> git log
commit 2eba8869bb72561f3f19f9b675ec74ba738f2443 (HEAD -> master, origin/master, origin/HEAD)
Author: Stefan Ritt <stefan.ritt@psi.ch>
Date: Fri May 3 16:04:21 2024 +0200
Removed unused variables
commit 8f942d1d18cc7d4d9b12f049dfd67284e3289963
Author: Stefan Ritt <stefan.ritt@psi.ch>
Date: Fri May 3 15:50:17 2024 +0200
Disabled attachment file retrieval to prevent poxy mis-use
commit 3020557a2b52cc9c460b80313c7c61c3ee014896
Author: Stefan Ritt <stefan.ritt@psi.ch>
Date: Tue Apr 16 13:29:35 2024 +0200
Fixed typos
commit 3876ffa2cc22a355cad8da642cb6f5a35884597a
Author: Stefan Ritt <stefan.ritt@psi.ch>
Date: Mon Apr 15 18:04:52 2024 +0200
Fixed line break
commit a644db7f2c14210e8014dc2a3dc9960e1382ccc1
Author: Stefan Ritt <stefan.ritt@psi.ch>
Date: Mon Apr 15 18:00:54 2024 +0200
Updated MacOSX command
commit fe60aaf0c41dcfafa50042e415f576faf82b1d4b
Author: Stefan Ritt <stefan.ritt@psi.ch>
Date: Thu Mar 14 21:17:01 2024 +0100
Fixed wrong number of attachments display
Broken pipe
iris00:~/packages/elog> |
|
read-only elog server, posted by Germano Massullo on Mon Oct 23 15:20:32 2023
|
Good day. I am writing this post to ask how I can turn an elog website into a read-only version that will stay online for historical documention purposes.
I tried to search on Elog documentation but I had no success
Thank you and have a nice day |
|
Re: read-only elog server, posted by Stefan Ritt on Mon Oct 23 16:15:06 2023
|
Use
Menu commands = List, Find, Help
to remove all command which let you create or edit entries (New, Reply, Edit, ...)
Then do the same with "List menu commands = ..."
/Stefan
| Germano Massullo wrote: |
|
Good day. I am writing this post to ask how I can turn an elog website into a read-only version that will stay online for historical documention purposes.
I tried to search on Elog documentation but I had no success
Thank you and have a nice day
|
|
|
Re: read-only elog server, posted by Bockjoo Kim on Sun Apr 28 14:45:22 2024
|
Hi,
Could you be more specific? Where do I get the 'Menu commands"?
Thanks,
Bockjoo
| Stefan Ritt wrote: |
|
Use
Menu commands = List, Find, Help
to remove all command which let you create or edit entries (New, Reply, Edit, ...)
Then do the same with "List menu commands = ..."
/Stefan
| Germano Massullo wrote: |
|
Good day. I am writing this post to ask how I can turn an elog website into a read-only version that will stay online for historical documention purposes.
I tried to search on Elog documentation but I had no success
Thank you and have a nice day
|
|
|
Re: read-only elog server, posted by Laurent Jean-Rigaud on Mon Apr 29 15:22:37 2024 
|
The menu is the line with available functions, customizable in logbooks config
Also, these are buttons in logbook edit view.
| Bockjoo Kim wrote: |
|
Hi,
Could you be more specific? Where do I get the 'Menu commands"?
Thanks,
Bockjoo
| Stefan Ritt wrote: |
|
Use
Menu commands = List, Find, Help
to remove all command which let you create or edit entries (New, Reply, Edit, ...)
Then do the same with "List menu commands = ..."
/Stefan
| Germano Massullo wrote: |
|
Good day. I am writing this post to ask how I can turn an elog website into a read-only version that will stay online for historical documention purposes.
I tried to search on Elog documentation but I had no success
Thank you and have a nice day
|
|
|
|
|
Imagemagick not working on Ubuntu, posted by scott on Wed Apr 24 12:55:25 2024
|
Hi Team,
I have set up Elog on the Ubuntu server using the compile and install method. I have installed ImageMagick and GhostScript along with that.
You can find "ImageMagick detected" mentioned in the service status provided below:
=======================================================================
● elogd.service - The ELOG Server
Loaded: loaded (/lib/systemd/system/elogd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2024-04-23 08:59:50 UTC; 1 day 1h ago
Docs: man:elogd(8)
man:elog(8)
Main PID: 858 (elogd)
Tasks: 1 (limit: 9365)
Memory: 163.5M
CPU: 25.825s
CGroup: /system.slice/elogd.service
└─858 /usr/local/sbin/elogd -D -c /usr/local/elog/elogd.cfg
Apr 23 08:59:50 server1.com systemd[1]: Starting The ELOG Server...
Apr 23 08:59:50 server1.com elogd[858]: elogd 3.1.5 built Mar 21 2024, 17:20:15
Apr 23 08:59:50 server1.com systemd[1]: Started The ELOG Server.
Apr 23 08:59:50 server1.com elogd[858]: revision fe60aaf0
Apr 23 08:59:50 server1.com elogd[858]: CKeditor detected
Apr 23 08:59:51 server1.com elogd[858]: ImageMagick detected
Apr 23 09:00:08 server1.com elogd[858]: Server listening on port 8080
=======================================================================
root@server1# identify -version
Version: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
Copyright: (C) 1999-2021 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC Modules OpenMP(4.5)
Delegates (built-in): bzlib djvu fftw fontconfig freetype heic jbig jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png tiff webp wmf x xml zlib
=======================================================================
However, the ImageMagick was found to be not working on my logbook. See the below error on the logbook.
Cannot create thumbnail, please check ImageMagick installation
I have attached a screenshot for reference.
Please could someone help me how to solve this?
Many thanks,
Scott
|
|
Re: Imagemagick not working on Ubuntu, posted by Konstantin Olchanski on Thu Apr 25 02:11:08 2024
|
Please see https://daq00.triumf.ca/DaqWiki/index.php/Ubuntu#Enable_elog_PDF_preview
see https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion
xemacs -nw /etc/ImageMagick-6/policy.xml
remove this section at the end:
<!-- disable ghostscript format types -->
<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="PS2" />
<policy domain="coder" rights="none" pattern="PS3" />
<policy domain="coder" rights="none" pattern="EPS" />
<policy domain="coder" rights="none" pattern="PDF" />
<policy domain="coder" rights="none" pattern="XPS" />
K.O. |
Suggestion to update Mac OS X instructions in ELOG Administrator's Guide, posted by Andreas Warburton on Sat Mar 9 17:17:02 2024
|
The section of the ELOG Administrator's Guide https://elog.psi.ch/elog/adminguide.html describing how to build and install ELOG on a Mac OS X system has worked well for me for several years, even though there have been warnings that the "load" and "unload" subcommands of the "launchctl" command have been deprecated for some time. After trying my luck again on a new Mac with the latest operating system, I encountered errors of the type "Load failed: 5: Input/output error" when attempting to follow these instructions.
After a bit of searching around, I used information at the page https://www.alansiu.net/2023/11/15/launchctl-new-subcommand-basics-for-macos/ to deploy the more current subcommands as follows:
sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl disable system/ch.psi.elogd
Once the above can be verified, perhaps the instructions in the Administrator's Guide can be updated accordingly.
|
|
Re: Suggestion to update Mac OS X instructions in ELOG Administrator's Guide, posted by Andreas Warburton on Sun Mar 10 04:25:43 2024
|
Here's a more complete/correct set of the updated commands:
sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl bootout system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl disable system/ch.psi.elogd
Cheers,
Andreas
| Andreas Warburton wrote: |
|
The section of the ELOG Administrator's Guide https://elog.psi.ch/elog/adminguide.html describing how to build and install ELOG on a Mac OS X system has worked well for me for several years, even though there have been warnings that the "load" and "unload" subcommands of the "launchctl" command have been deprecated for some time. After trying my luck again on a new Mac with the latest operating system, I encountered errors of the type "Load failed: 5: Input/output error" when attempting to follow these instructions.
After a bit of searching around, I used information at the page https://www.alansiu.net/2023/11/15/launchctl-new-subcommand-basics-for-macos/ to deploy the more current subcommands as follows:
sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl disable system/ch.psi.elogd
Once the above can be verified, perhaps the instructions in the Administrator's Guide can be updated accordingly.
|
|
|
Re: Suggestion to update Mac OS X instructions in ELOG Administrator's Guide, posted by Stefan Ritt on Mon Apr 15 18:05:27 2024
|
Thanks for the info, I updated the adminguide.
Stefan
| Andreas Warburton wrote: |
|
Here's a more complete/correct set of the updated commands:
sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl bootout system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl disable system/ch.psi.elogd
Cheers,
Andreas
| Andreas Warburton wrote: |
|
The section of the ELOG Administrator's Guide https://elog.psi.ch/elog/adminguide.html describing how to build and install ELOG on a Mac OS X system has worked well for me for several years, even though there have been warnings that the "load" and "unload" subcommands of the "launchctl" command have been deprecated for some time. After trying my luck again on a new Mac with the latest operating system, I encountered errors of the type "Load failed: 5: Input/output error" when attempting to follow these instructions.
After a bit of searching around, I used information at the page https://www.alansiu.net/2023/11/15/launchctl-new-subcommand-basics-for-macos/ to deploy the more current subcommands as follows:
sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl disable system/ch.psi.elogd
Once the above can be verified, perhaps the instructions in the Administrator's Guide can be updated accordingly.
|
|
|
|
Re: Suggestion to update Mac OS X instructions in ELOG Administrator's Guide, posted by Andreas Warburton on Tue Apr 16 13:20:01 2024
|
Hi Stefan, Thanks a lot for implementing the updated commands. I noted that there are a few typos that could cause people confusion if not fixed:
In one case, "launchctl" is misspelled.
Confusingly, I think the two lines containing the 'enable' and 'disable' commands use the contiguous text string "system/ch.psi.elogd" (no space), whereas the two lines containing the 'bootstrap' and 'bootout' commands use the phrase "system /Library/LaunchDaemons/ch.psi.elogd.plist" (note space after 'system').
Many thanks, Andreas W.
|
Stefan Ritt wrote:
|
|
Thanks for the info, I updated the adminguide.
Stefan
| Andreas Warburton wrote: |
|
Here's a more complete/correct set of the updated commands:
sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl bootout system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl disable system/ch.psi.elogd
Cheers,
Andreas
| Andreas Warburton wrote: |
|
The section of the ELOG Administrator's Guide https://elog.psi.ch/elog/adminguide.html describing how to build and install ELOG on a Mac OS X system has worked well for me for several years, even though there have been warnings that the "load" and "unload" subcommands of the "launchctl" command have been deprecated for some time. After trying my luck again on a new Mac with the latest operating system, I encountered errors of the type "Load failed: 5: Input/output error" when attempting to follow these instructions.
After a bit of searching around, I used information at the page https://www.alansiu.net/2023/11/15/launchctl-new-subcommand-basics-for-macos/ to deploy the more current subcommands as follows:
sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl disable system/ch.psi.elogd
Once the above can be verified, perhaps the instructions in the Administrator's Guide can be updated accordingly.
|
|
|
|
|
Re: Suggestion to update Mac OS X instructions in ELOG Administrator's Guide, posted by Stefan Ritt on Tue Apr 16 13:31:02 2024
|
Thanks, fixed.
Stefan
| Andreas Warburton wrote: |
|
Hi Stefan, Thanks a lot for implementing the updated commands. I noted that there are a few typos that could cause people confusion if not fixed:
In one case, "launchctl" is misspelled.
Confusingly, I think the two lines containing the 'enable' and 'disable' commands use the contiguous text string "system/ch.psi.elogd" (no space), whereas the two lines containing the 'bootstrap' and 'bootout' commands use the phrase "system /Library/LaunchDaemons/ch.psi.elogd.plist" (note space after 'system').
Many thanks, Andreas W.
|
|
|