Re: Default "Author" when replying to a log entry, posted by Jan Just Keijser on Tue Feb 1 16:43:34 2022
|
Excellent, exactly what I was looking for, many thanks!
| Stefan Ritt wrote: |
|
As you can see, on this forum the author for replies is correct. This is done via the config option:
Preset on reply Author = $long_name
| Jan Just Keijser wrote: |
|
what is the default value for "Author" when replying to a log entry ? I now see that for each reply to a log entry, the value of "Author" is set to the value of the author of the original entry - this makes it very hard to see which user has replied to a particular log entry, especially when users start replying to replies etc.
This is with elog 3.1.4-3 on CentOS 7
|
|
|
|
Re: Vulnerability?, posted by Jan Just Keijser on Mon Mar 7 17:46:39 2022
|
> > 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. |
Re: Vulnerability?, posted by Jan Just Keijser on Wed Mar 9 17:55:31 2022 
|
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 |
|
Re: Vulnerability?, posted by Jan Just Keijser on Tue Apr 19 17:02:57 2022
|
> > 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.... |
|
Re: Vulnerability?, posted by Jan Just Keijser on Fri Apr 22 17:10:24 2022
|
> > > > 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.
|
Pasting pictures from clipboard does not work anymore (firefox 39), posted by Jan Henry Hetzel on Tue Jul 14 10:10:54 2015
|
| Hallo,
as I have already written in the title, my problem is that after uprgrading my firefox to version 39 I cannot include pictures from clipboard. A downgrade to a previous version of firefox helped. But as this is not recommended I wanted to ask if there is a workaround or if I should inform the author of the "imagepaste"-extension of the CKEditor?
Best regards,
Jan |
Re: Pasting pictures from clipboard does not work anymore (firefox 39), posted by Jan Henry Hetzel on Thu Jul 23 08:19:38 2015
|
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
| Stefan Ritt wrote: |
|
I'm not aware of any workaround, so you might ask the author. Once you find a solution, I'm happy to include it in the distribution.
Stefan
| Jan Henry Hetzel wrote: |
| Hallo, as I have already written in the title, my problem is that after uprgrading my firefox to version 39 I cannot include pictures from clipboard. A downgrade to a previous version of firefox helped. But as this is not recommended I wanted to ask if there is a workaround or if I should inform the author of the "imagepaste"-extension of the CKEditor? Best regards, Jan |
|
|
|
Re: PAM authentication question, posted by Jan Christoph Terasa on Sun Nov 17 14:55:11 2019
|
| David Wallis wrote: |
|
I'm testing the PAM authentication feature, and have a couple questions, a suggestion, and a comment.
First the comment... it was pretty easy to get working, and is exactly what we need here, so thanks! Our PAM stack here is designed to allow logins with Active Directory, LDAP, or local accounts, so the PAM option preserves all of that.
The suggestion: In order to make it work, I had to add a symbolic link in /etc/pam.d:
elogd -> system-auth
That might be considered for addition to the documentation (this was on Red Hat Enterprise Linux 7.7)
The questions:
- The docs indicate that "Self register" must be set to >= 1, but in the code (elogd.c, line 26453), if the PAM module is enabled, Self register is overriden to 0. The result is that no "register as new user" link is displayed on the login screen. Is that the intent?
- Related... can PAM and File authentication both be enabled? We have some logbooks that are used by both internal people (with an A/D account) and outside collaborators that get local elog accounts. This works with LDAP + File, can it work with PAM?
Thanks in advance!
|
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 |
|