| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68577
|
Wed Feb 8 18:16:30 2017 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.1 | Re: Possible misuse of email headers Message-Id and In-Reply-To |
A pull request would be highy appreciated, because you can then test it thoroughly on your side. Adding a random number to the message id is simple. "Reply-to" indeed does not make sense since elog cannot receive emails. Most sites use a generic "noreply@<domain>" to indicate to the user that a reply does not make sense. I guess the "Reply-to" does not have to be unique, right?
| fbretel wrote: |
|
Hi,
As mentionned before, we happen to fail to receive email messages related to updates on elog entries at our site. My understanding is that the SMTP header Message-Id MUST be unique for each email message. Whereas all elogd email messages get something like <logbook>-<entryId>@<domain>. See source code. For this header to become unique, there should be a random part in it.
Having the same Message-Id in multiple email messages results in only the first one being delivered on some email systems.
Moreover, elogd sets the In-Reply-To: header in the same manner (<logbook>-<entryId>@<domain>). Which is incorrect because this header relates to email messages, not elog entries, and should contain the email Message-Id of the email message to which it replies, itself handled by the email messaing system. But elogd hasn't received any email messsage in the first place. So I believe this header should simply be dropped.
I think I can provide a pull request on bitbucket for the Message-Id issue, and probably also for the In-Reply-To: if you decide it can be removed.
Cheers
|
|
|
68579
|
Wed Mar 15 16:42:35 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.1 | Re: Possible misuse of email headers Message-Id and In-Reply-To |
Pull-request merged.
|
|
68590
|
Wed Apr 5 13:16:34 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | V3.1.0-3c6435e | Re: Elog not see image magick |
Must be your PATH environment variable. You have usually different paths when running interactively or as a service. Try to change the path seen by services, or put the ImageMagick executable in the same directory as elogd.
Stefan
| christian wrote: |
|
Update:
While the image scaling via ImageMagick works when running elog manually it doesn't when running elog as a service. The service is hosted in the same user environment that allows image scaling with elog started manually. What else could go wrong?
Christian
|
|
|
68594
|
Fri Apr 7 10:22:03 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | V3.1.0-3c6435e | Re: Elog not see image magick |
I don't undersand myself fully how services see the environment. Like if they see the PATH at all. In some occations it helped to run the service not under the SYSTEM account, but under the (admin) account of a real user.
Stefan
| christian wrote: |
|
This I do not fully understand: To my understanding the PATH environment variable (includes the ImageMagick path) is a system variable and should be accessable from any account and should be valid under any conditions. Am I wrong? Additionally, I tried adding the system Path variable to the user specific variables for that user that runs the service (Path = %Path%) in the system settings. Finally, I tried copying the imdisplay.exe (ImageMagick executable) and convert.exe (used for the software detection) from the ImageMagick installation directory to the same directory as elogd. Neither of these approaches was successfull.
Christian
| Stefan Ritt wrote: |
|
Must be your PATH environment variable. You have usually different paths when running interactively or as a service. Try to change the path seen by services, or put the ImageMagick executable in the same directory as elogd.
Stefan
| christian wrote: |
|
Update:
While the image scaling via ImageMagick works when running elog manually it doesn't when running elog as a service. The service is hosted in the same user environment that allows image scaling with elog started manually. What else could go wrong?
Christian
|
|
|
|
|
68595
|
Fri Apr 7 10:24:31 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | V3.1.0-3c6435e | Re: Elog not see image magick |
Ah sorry. I recall now: Under Windows, calling subprocesses from a service does not work at all. After a couple of days of work I was not able to get this running. If somebody has some idea, I'm happy to try it. So most people use the elogd daemon in the background only under Linux.
Stefan
| Stefan Ritt wrote: |
|
I don't undersand myself fully how services see the environment. Like if they see the PATH at all. In some occations it helped to run the service not under the SYSTEM account, but under the (admin) account of a real user.
Stefan
| christian wrote: |
|
This I do not fully understand: To my understanding the PATH environment variable (includes the ImageMagick path) is a system variable and should be accessable from any account and should be valid under any conditions. Am I wrong? Additionally, I tried adding the system Path variable to the user specific variables for that user that runs the service (Path = %Path%) in the system settings. Finally, I tried copying the imdisplay.exe (ImageMagick executable) and convert.exe (used for the software detection) from the ImageMagick installation directory to the same directory as elogd. Neither of these approaches was successfull.
Christian
| Stefan Ritt wrote: |
|
Must be your PATH environment variable. You have usually different paths when running interactively or as a service. Try to change the path seen by services, or put the ImageMagick executable in the same directory as elogd.
Stefan
| christian wrote: |
|
Update:
While the image scaling via ImageMagick works when running elog manually it doesn't when running elog as a service. The service is hosted in the same user environment that allows image scaling with elog started manually. What else could go wrong?
Christian
|
|
|
|
|
|
68597
|
Fri Apr 7 12:16:24 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.1 | Re: command line and apache+ldap authentication |
Hi, the elog command line client does not know anything about Apache authentication, therefore the authentication with the elog username/password fails. As an alternative to the command line client you can use the "curl" utility (available under Linux). This tools has the "-u" flag, which works with Apache. The tricky thing is now to "emulate" your browser submitting an entry. You can do
$ curl -u <username>:<password> -F cmd=Submit -F Author=CURL -F Text="This is the CURL text" http://<your host>:8080/<logbook>
(of course your attributes might be different than "Author"). If you have a multiline text body, you can read that from a file (in this case "file.txt"):
$ curl -u <username>:<password> -F cmd=Submit -F Author=CURL -F Text="@file.txt" http://<your host>:8080/<logbook>
When I wrote "elog" orginiallly (199x?), "curl" was not available or at least I didn't know of. Right now it almoste completely can replace the elog tool.
Stefan |
|
68604
|
Thu Apr 20 12:59:24 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.9.2 | Re: Full anonymous access |
Sure. Just remove "Password file = ..." and any guest menu.
Stefan
| K wrote: |
|
How can i configure eLog to be used completely anonymous without the need to log in?
I tried menu and guest menu settings without luck. I do not use password files. With earlier versions this was easy to set up...
Thanks in advance
|
|
|
68606
|
Thu Apr 20 13:45:42 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.9.2 | Re: Full anonymous access |
Version 2.9.2 is hopelessly outdated. Please upgrade to the current version on bitbucket. You also might have to delete any cookie in the browser sent to the elog server.
| K wrote: |
|
Does not work.
Clean install (debian 8 x64, with aptitude), only thing i've changed in the config is "URL"-parameter (global section) and redirection with Apache. No luck. Edit or delete gives an error "Error: Command "Delete" not allowed", "New" opens login-windows.
Now i removed all (guest) menu and URL settings a use it directly (port 8080), still no luck. "Error: Command "Delete" not allowed". When i click on "New" a login-windows opens.
Tested with the demo-logbook.
| Stefan Ritt wrote: |
|
Sure. Just remove "Password file = ..." and any guest menu.
Stefan
| K wrote: |
|
How can i configure eLog to be used completely anonymous without the need to log in?
I tried menu and guest menu settings without luck. I do not use password files. With earlier versions this was easy to set up...
Thanks in advance
|
|
|
|