Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 790 of 796  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Iconup Author Author Email Category OS ELOG Version Subject
  68460   Wed Nov 16 17:12:40 2016 Warning Grant Jeffcotegrant@jeffcote.orgRequestAll3.1.2Re: Cancel button missing when editing an entry

Andreas,

Doesn't using the Save Drafts = 0 option result in the old 'Back' button returning (replacing the Delete option) meaning you can revert back to your old (unmodified) version without saving, sure it doesn't save a draft but I'd rather be able to return back and lose the changes I didn't want then mess up an old entry, I guess the back button on the browser could also do what you want?

The issue I had was that entries were being deleted accidently by persons other than those that created them, I reduced the edit time to try and mitigate it but ended up going back to what we had in Ver 2.9.2, a 'Back' button.

Grant

Stefan Ritt wrote:

The problem is that the elog database does not allow for a copy of an entry before you make modifications (and therefore get a "draft"). This is actually very simila to other note taking programs. I use Evernote, which constantly synchronizes between devices, and there I also cannot go back to the version before I started making modification. What one would need is a version system (and Evernote has one), so you can go back to the previous verison, the pre-previous version and so on. But this requires a complete redesign of the elog database.

A quick and dirty solution would be to store the origianal entry inside the browser (using JavaScript). You could then restore the initial version with a "cancel" button. But this mechanism relies then on the browser. If you just leave the page, there is no way the browser can put back the old version.

Stefan

Andreas Luedeke wrote:

If I edit an old entry, and do some mistake while editing, then there is currently no way to savely discard the changes.

The problem is that the entry will become a draft: if I close the window without saving, then the whole entry is gone: it will be converted into a draft entry. But the draft does contain my changes, it is not the originally saved entry!

The draft mechanism should keep a copy of the entry before I opened it in edit mode, and allow to go back to that copy. The edit form has currently the buttons "Submit", "Save", "Preview" and "Delete"; it should have in addition the button "Cancel", that just closes the edit window without saving the entry and even deleting the draft that was saved while the entry was modified. This should bring you back to the previous list view.

Is anyone out there in favour of this change?

 

 

  68549   Sat Jan 14 08:27:42 2017 Warning Andreas Warburtonawarburt@physics.mcgill.caBug reportLinuxV3.1.2Re: elogd crashes during SSL Mirror operations involving attachments

For the time being, I am deeming ELOG 3.1.2 unusable with https (SSL = 1) functionality on my "Debian GNU/Linux 7 (wheezy)" server with "OpenSSL 1.0.1t", due to the described apparent issues with SSL.  Reverting to http (SSL = 0) brings back my ability to upload attachments and synchronize with a remote elogd running on a MacOS laptop.

Interestingly, my records indicate that I suffered a problem with very similar symptoms back in 2011, with version 2.8.0.  The problem at that time, which is acknowledged in the Changelog as "Fixed bug with SSL connection shutdown", got fixed in version 2.9.0.  Perhaps, when the "Replaced insecure SSLv23 with TLSv1 method" change was implemented for version 3.0.0, a similar issue was (re-)introduced?

It would of course be best if this issue were resolvable soon, due to the security vulnerabilities of http versus https.  Thank you in advance for any efforts!

Best regards,

Andreas Warburton

Andreas Warburton wrote:

When I switch from SSL = 1 to SSL = 0 and I use http:// instead of https://, the ability to upload attachments to logbook entries returns.  With both Chrome and Safari browsers, with SSL = 1 the file upload hangs after only a small percentage of the file has been uploaded.  I ran the following openssl diagnostic on my elogd port.  Would anyone have advice on what might be causing such errors?

tapajo [/usr/local/elog/elog-latest] openssl s_client -connect elog.hep.xxx.xx:80xx -state -nbio | grep "^SSL"

SSL_connect:before/connect initialization

SSL_connect:SSLv2/v3 write client hello A

SSL_connect:error in SSLv2/v3 read server hello A

SSL_connect:unknown state

depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost

verify error:num=18:self signed certificate

verify return:1

depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost

verify return:1

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:error in unknown state

SSL_connect:error in unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL handshake has read 1733 bytes and written 871 bytes

SSL-Session:

SSL3 alert read:warning:close notify

SSL3 alert write:warning:close notify

Andreas Warburton wrote:

The attached screenshot shows the behaviour after doing a synchronization (with Mirror simulate = 1) following first having ensured that the local (Mac) and remote (linux) ELOGs initially showed "All entries identical" when doing a simulated synchronization, and then having edited local entries 9707 and 9709 by uploading (different) attachments to them.

The fact that the synchronization is suggesting to renumber two different entry IDs to the same number looks like a bug.

Best regards,

Andreas W.

Andreas Warburton wrote:

My MacOS (10.12.2) elogd version V3.1.2 is a recent git commit (edc5e85), due to the fix to my earlier-described issue solved in the thread here: https://midas.psi.ch/elogs/Forum/68519.

I am trying to (re-)set up Mirror functionality with a linux server running the standard public (V3.1.2-bd75964).  I had initially updated the linux server so that it also had the latest git commit (edc5e85), but could then not even add new logbook entries that involved attachments to it.  I therefore rolled the linux server back to the standard public 3.1.2 version.

On the remote Mac, synchronizations usually look like they are going to work fine, with Mirror simulate = 1 switched on.  After I set Mirror simulate = 0, and if the server and remote logbook are already identical, I *occasionally* get the proper "All Entries Identical" synchronization result.  Unfortunately, this is very rare, and usually there is a failure whereby the remote (Mac) logbook decides that a significant fraction of its entries (usually sequential, from some seemingly random entry all the way up to the last entry) are missing on the linux server and need to be submitted back to the server from the remote Mac.

When the local and remote logbooks are not identical, and a record in need of synchronization contains an attachment, there is again destructive behaviour similar to that described above, except that the Mac elogd executable usually crashes.  (As in the case of the already-identical synchronizations described above, I only tested this after observing the correct expected behaviour first with Mirror simulate = 1.)

I'd be grateful for some help/suggestions.  My current testing suggests that my problems are likely not elog-content dependent.  (The logbook now undergoing synching has less than 10 entries in it.)

More generally, the issue of having things behave fine with Mirror simulate = 1, but then experiencing corruption/damage when switching to Mirror simulate = 0 seems serious to me.

Many thanks, Andreas

 

 

 

 

  68552   Thu Jan 19 12:56:51 2017 Warning Andreas Warburtonawarburt@physics.mcgill.caBug reportLinuxV3.1.2Re: elogd crashes during SSL Mirror operations involving attachments

Further to my comment in https://midas.psi.ch/elogs/Forum/68549, if the described synchronization requires attachment(s) to be transferred from my Mac laptop to the Debian linux server (with SSL = 0 set), it fails in all the tests that I tried.

To check whether these problems are linked to the OpenSSL version on the linux server, we also tried building an elogd executable using 1.0.2j instead of 1.0.1t.  This did not appear to change/improve the behaviour.

I'd like to keep using ELOG into the foreseeable future.  Don't hesitate to contact me if you'd like me to beta test any upcoming releases.  I'd appreciate having the earlier mirroring and attachment-handling functionality back again.

Best regards,

Andreas W.

 

Andreas Warburton wrote:

For the time being, I am deeming ELOG 3.1.2 unusable with https (SSL = 1) functionality on my "Debian GNU/Linux 7 (wheezy)" server with "OpenSSL 1.0.1t", due to the described apparent issues with SSL.  Reverting to http (SSL = 0) brings back my ability to upload attachments and synchronize with a remote elogd running on a MacOS laptop.

Interestingly, my records indicate that I suffered a problem with very similar symptoms back in 2011, with version 2.8.0.  The problem at that time, which is acknowledged in the Changelog as "Fixed bug with SSL connection shutdown", got fixed in version 2.9.0.  Perhaps, when the "Replaced insecure SSLv23 with TLSv1 method" change was implemented for version 3.0.0, a similar issue was (re-)introduced?

It would of course be best if this issue were resolvable soon, due to the security vulnerabilities of http versus https.  Thank you in advance for any efforts!

Best regards,

Andreas Warburton

Andreas Warburton wrote:

When I switch from SSL = 1 to SSL = 0 and I use http:// instead of https://, the ability to upload attachments to logbook entries returns.  With both Chrome and Safari browsers, with SSL = 1 the file upload hangs after only a small percentage of the file has been uploaded.  I ran the following openssl diagnostic on my elogd port.  Would anyone have advice on what might be causing such errors?

tapajo [/usr/local/elog/elog-latest] openssl s_client -connect elog.hep.xxx.xx:80xx -state -nbio | grep "^SSL"

SSL_connect:before/connect initialization

SSL_connect:SSLv2/v3 write client hello A

SSL_connect:error in SSLv2/v3 read server hello A

SSL_connect:unknown state

depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost

verify error:num=18:self signed certificate

verify return:1

depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost

verify return:1

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL_connect:error in unknown state

SSL_connect:error in unknown state

SSL_connect:unknown state

SSL_connect:unknown state

SSL handshake has read 1733 bytes and written 871 bytes

SSL-Session:

SSL3 alert read:warning:close notify

SSL3 alert write:warning:close notify

Andreas Warburton wrote:

The attached screenshot shows the behaviour after doing a synchronization (with Mirror simulate = 1) following first having ensured that the local (Mac) and remote (linux) ELOGs initially showed "All entries identical" when doing a simulated synchronization, and then having edited local entries 9707 and 9709 by uploading (different) attachments to them.

The fact that the synchronization is suggesting to renumber two different entry IDs to the same number looks like a bug.

Best regards,

Andreas W.

Andreas Warburton wrote:

My MacOS (10.12.2) elogd version V3.1.2 is a recent git commit (edc5e85), due to the fix to my earlier-described issue solved in the thread here: https://midas.psi.ch/elogs/Forum/68519.

I am trying to (re-)set up Mirror functionality with a linux server running the standard public (V3.1.2-bd75964).  I had initially updated the linux server so that it also had the latest git commit (edc5e85), but could then not even add new logbook entries that involved attachments to it.  I therefore rolled the linux server back to the standard public 3.1.2 version.

On the remote Mac, synchronizations usually look like they are going to work fine, with Mirror simulate = 1 switched on.  After I set Mirror simulate = 0, and if the server and remote logbook are already identical, I *occasionally* get the proper "All Entries Identical" synchronization result.  Unfortunately, this is very rare, and usually there is a failure whereby the remote (Mac) logbook decides that a significant fraction of its entries (usually sequential, from some seemingly random entry all the way up to the last entry) are missing on the linux server and need to be submitted back to the server from the remote Mac.

When the local and remote logbooks are not identical, and a record in need of synchronization contains an attachment, there is again destructive behaviour similar to that described above, except that the Mac elogd executable usually crashes.  (As in the case of the already-identical synchronizations described above, I only tested this after observing the correct expected behaviour first with Mirror simulate = 1.)

I'd be grateful for some help/suggestions.  My current testing suggests that my problems are likely not elog-content dependent.  (The logbook now undergoing synching has less than 10 entries in it.)

More generally, the issue of having things behave fine with Mirror simulate = 1, but then experiencing corruption/damage when switching to Mirror simulate = 0 seems serious to me.

Many thanks, Andreas

 

 

 

 

 

  Draft   Mon Feb 6 15:59:04 2017 Warning sohail bhattisohail_bhatti@yahoo.comRequestWindows3.1.2Re: calculate diff of 2 date(s)

Alex Kühnel wrote:

thx!

Stefan Ritt wrote:

There is the "subst on edit = ..." option you should use in addition.

Stefan

Alex Kühnel wrote:

is ist possible that subst only works for the initial create of a logbook entry? when I change/edit one of the parameter "Einsatzbegin" or "Einsatzende" the "Einsatzzeit" is not changed.

regards

/alex

Alex Kühnel wrote:

I found the solution in the forum :-)

subst Einsatzzeit = $shell(/usr/local/elog/diff.sh \"$Einsatzbeginn\" \"$Einsatzende\")

and diff.sh is

#!/bin/sh
#set -x
s1=$(date -d "$1" +%s)
s2=$(date -d "$2" +%s)
d=$(echo "($s2-$s1)/60"|bc -lq)
printf "%.0f Minuten" $d
 

 

 

Alex Kühnel wrote:

hi

I have an elogsystem for documenting emergency services. I have a starttime and an endtime. Is it possible to calculate the diff between the 2 timestamps and convert it to minutes?

 

Attributes = Bereitschafts Kalender Woche, Bereitschafts Woche, Einsatzbeginn, Einsatzende, Einsatzzeit, Telefon Nummer, Station, Status, Problem 
Options Status= Offen{1}, Erledigt{2}, Geschlossen{3}

......

Type Einsatzbeginn = datetime
Type Einsatzende = datetime

....

Subst Einsatzzeit  = $shell(Einsatzende - Einsatzbeginn)  

 

regards

/alex

 

 

 

 

 

  68627   Wed May 31 13:28:51 2017 Warning Andreas Luedekeandreas.luedeke@psi.chBug reportLinux3.1.1Re: inactive users
> Hi,
>   I reopen this old thread since I'm having a similar problem.
> 
> I'm running ELOG V3.1.1-0767eb0 on ubuntu with webserver authentication, and I'd like to remove 'active' checkbox as well.
> 
> The problem that we found is that if any user click on the [Set None] button at the bottom of the Config page in order to unsubscribe from all mail notification,
> *all* the checkbox are toggled, not only those for the email notification. And this includes also the "active user" as well.

I can confirm that this bug is present even in this forum and in my current version (ELOG V3.1.3-aded4ae).
And I am positive that this is a bug: it was certainly not the intended behaviour.
  68708   Tue Dec 5 15:30:43 2017 Warning Christian Herzogherzog@phys.ethz.chQuestionLinuxELOG V3.1.2possible DOS vulnerability with negative Content-Length field

Hi,

 

a routine scan revealed a possible DOS attack vector: sending an invalid POST HTTP request with a negative Content-Length field crashes our elog instance, leading to service unavailability.

 

thanks,

-Christian

 

 

-- 
Dr. Christian Herzog <herzog@phys.ethz.ch>  support: +41 44 633 26 68
IT Services Group, HPT H 8                    voice: +41 44 633 39 50
Department of Physics, ETH Zurich           
8093 Zurich, Switzerland                     http://nic.phys.ethz.ch/

 

  68715   Mon Jan 15 15:56:07 2018 Warning Tim Schelfhouttimpieworks@gmail.comQuestionWindowsELOG V3.1.3-fd7Unsafe browsing

Hello there,

Can anyone point out to me how I can avoid the unsafe browsing when accessing our local ELOG?  
Browsing with chrome and always getting the unsafe browsing page. One has to go through the advanced
button to continue ...

I once had my setup with SSL certificate (local signed, not through the CA) but I somehow cannot get it
to work anymore.   Just create a local certificate and copy the certificates to all browsers that access the ELOG site, no?

Anyway, a small guide would be great.

  68724   Sat Jan 27 03:37:11 2018 Warning Peter Kpkravt@gmail.comBug reportLinuxV3.1.2-bd75964Entries disappear after editing

Dear elog community,

We have a problem with elog V3.1.2-bd75964.
Sometimes entries disappear from the list after editing.
I found them in the .log files with attributes

Locked by:
Draft:

But they are not in the list anymore!
The only solution by now is manually remove these two attributes from the file,
but this is terrible.

How can I fix this?

Thanks,
Peter.

 

ELOG V3.1.5-2eba886