Excellent, exactly what I was looking for, many thanks!

> > I trust Stefan is reading this thread and will do something about it. My vote would
> > be to remove the download link to the windows executables and ask Debian to remove
> > the elog package. I think they have a way for upstream developers (Stefan) to request
> > removal of unmaintained out-of-date insecure versions of their stuff. ROOT
> > was in the same situation years ago, the Debian package for ROOT was very old version,
> > also built incorrectly, and everybody complained to us that our stuff does
> > not work (midas, rootana, etc).
> 
> Yeah, I have to recompile the Windows version. Unfortunately my old Windows PC is gone, I
> switched now completely to MacOSX and Linux. Probably have to borrow something from somewhere.
> If anybody can compile the Windows version with the current source code I would be happy.
> 
> Stefan

FWIW: you could cross-compile on Linux using 
   make CC=x86_64-w64-mingw32-gcc CFLAGS="-D_MSC_VER -DHAVE_VASPRintF -Imxml" LIBS="-Wl,--allow-multiple-definition -ladvapi32 -lwsock32 -lssl -lcrypto"
or so I thought... with build 3.1.4 - 395e101 I did manage, finally. 
However, with the latest git version everything seems to have been renamed to .cxx files (though it's still plain C ??!?!?) and my quick and dirty compile hack did not work. The binaries do work, I can start the server and access it via the web interface.

I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
Attached is a zip file with the binaries.
I was not able to create a new installer, these are just the executables

> > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > Attached is a zip file with the binaries.
> > I was not able to create a new installer, these are just the executables
> 
> I tried to just exchange the attached binaries in my installation but this didn't worked.
> elogd was not able to start.

hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....

> > > > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > > > Attached is a zip file with the binaries.
> > > > I was not able to create a new installer, these are just the executables
> > > 
> > > I tried to just exchange the attached binaries in my installation but this didn't worked.
> > > elogd was not able to start.
> > 
> > hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....
> 
> Error message is:
> 
> Error 1053: The service did not respond to the start or control request in a timely fashion.
> 
> I have to admit that I'm doing all this on a Server 2012 machine.


Windows Server 2012 itself is almost EOL but it should still work, I believe.  I did see that the elog314-2.exe file is a Win32 binary whereas my binaries are 64bit. On Windows Server 2019 did not cause any issues.
Can you try the following
- extract the new elogd.exe binary somewhere , e.g. c:\temp\elogd.exe
- then type
  cd \Program Files (x86)\ELOG
  \temp\elogd.exe

- post the output/error code that you see.


  

Hi,

following the author of imagepaste one should upgrade the version of th CKEditor to a version >= 4.5. So replacing the folder ckeditor with a new version helped.

Best,

Jan

David, thank you for reporting on your findings regarding the PAM feature. I will look into the points you mentioned:

0. On my machines (Debian testing and stable) I did not have to add anything to /etc/pam.d, but apparently Debian just uses implicit defaults then, and REHL might insist on using excplicit settings. Adding a hint in the documentation is certainly useful, thank your for the suggestion. Maybe elog should provide a pam.d config file (which can be installed/adapted by package maintainers for various OSes).

1.+2. If I remember correctly, I intentionally disabled registration when using the PAM backend, because users will register using their passwd/LDAP/NIS users, and new users can only be regustered using the appropriate tools for the authentication mechanism used. This might not be correctly reflected in the docs, I will check that. In the light of question 2., I can also re-investigate that policy, so that logins will check against both the elog user database and PAM. Self-registering can then be enabled again, and new registrees will go to the elog database. I will try to bringthe code in line with how LDAP works.

regards,

Christoph