> Well, I bit the bullet and fixed all of these warnings. Took me like two days of work, but now should be fine.
> You might want to test it again.
Done. Only 2 sprintf() overruns remain, see below.
> I only have gcc 9.2.0, there it compiles now without warning.
Ubuntu LTS 20.04 is GCC 9.3.0. (And incoming Debian-11 based Ubuntu LTS 22.04 likely to be GCC 10.something).
If you do not have access, I can create an account for you on daq00.triumf.ca.
daq00: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 /usr/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 ‘void show_elog_list(LOGBOOK*, int, int, int, BOOL, char*)’:
src/elogd.cxx:21676:42: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1588 [-Wformat-overflow=]
21676 | sprintf(str, "Time format %s", attr_list[i]);
| ^~
In file included from /usr/include/stdio.h:867,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:34: note: ‘__builtin___sprintf_chk’ output between 13 and 150012 bytes into a destination
of size 1600
36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
37 | __bos (__s), __fmt, __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.cxx:21660:42: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1588 [-Wformat-overflow=]
21660 | sprintf(str, "Date format %s", attr_list[i]);
| ^~
In file included from /usr/include/stdio.h:867,
from src/elogd.h:42,
from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:34: note: ‘__builtin___sprintf_chk’ output between 13 and 150012 bytes into a destination
of size 1600
36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
37 | __bos (__s), __fmt, __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
daq00:elog$ gcc -v
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) |
Well, I bit the bullet and fixed all of these warnings. Took me like two days of work, but now should be fine. You might want to test it again. I only have gcc 9.2.0, there it compiles now without warning.
Stefan |
Recently I have had problems with ELOG not accepting the certificates (in this case from https://letsencrypt.org/) probably due to the old version of the SSL library of the binary distribution for Windows.
I have tried to follow the instructions to set up ELOG to work with Apache but they are probably old.
I have a simple solution for the Apache installation of XAMPP, the example is for two separate logbooks using each its own ELOG service on the same server:
1. I have set up the two ELOG to run as http://my.server.example.com:8080/ and as http://my.server.example.com:8081/
2. in c:\xampp\apache\conf\httpd.conf I have enabled the following (I am not sure if all the modules are really needed but this works for me):
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule headers_module modules/mod_headers.so
LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule xml2enc_module modules/mod_xml2enc.so
3. still in c:\xampp\apache\conf\httpd.conf, at the very end of the file I added the following:
ProxyRequests off
Redirect permanent /app1 https://my.server.example.com/app1/
ProxyPass /app1/ http://my.server.example.com:8080/
ProxyHTMLURLMap http://my.server.example.com:8080 /app1
Redirect permanent /app2 https://my.server.example.com/app2/
ProxyPass /app2/ http://my.server.example.com:8081/
ProxyHTMLURLMap http://my.server.example.com:8081 /app2
This way I can now connect to the two ELOG using https://my.server.example.com/app1/ and https://my.server.example.com/app2/ without troubles and no additional setting to either the configuration files of ELOG nor any need for virtual hosts, ...
I hope this might be of use.
|
Can you try the "top groups" option, which means putting each logbook into a separate top group as described in the documentation. For us this works well, new users are only added to the right password file. There is however the problem that as admin you might be logged in to several logbooks (as remembered in your browser via cookies), so you might want to log out from all logbooks first (or clear all cookies of elog), then log in to one logbook and add the user there. In worst case you still can modify the password file by hand, they are plain ASCII files. Only the password has to be entered later since it's encrypted.
Stefan
| Mark Delaney wrote: |
|
I expanded an elog server from 1 to 3 logbooks. For each logbook there is a separate password file defined.
When I try to add a new user in one of the 2 new logbooks using config => new user, it adds the user to the password file for the original logbook.
Have verified that access to the logbooks is controlled via the separate password files. If it would help to provide an example of the elogd.cfg or if I need to clarify further, let me know.
Any suggestions welcome.
Thanks. Mark.
|
|
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output 2 or more bytes (assuming 4097) into a
> destination of size 4096
Yeah, I like those warnings "up to 4097 bytes written to a buffer of 4096 bytes". And it's even not a security issue, since the source of the data comes from elogd.cfg which only the owner can modify.
Basically this calls to rewrite elog completely with std::string. Maybe one day I retire and have some time for that...
Stefan |